Notices

Sorry, I thought it was well-known because of this existing report in the bug tracker: http://bugs.bundyo.org/viewissue.php?issue_no=7

I thought that alluded to the black-on-black problem when using a dark theme like LCARS. I mean, MicroB essentially uses a "browser-only theme change" too, by virtue of Gecko using its own input field rendering rather than GTK+.

This is also why my above post came out a bit annoyed - "filed for weeks, no movement on it" .

Edit: Bug filed: http://bugs.bundyo.org/viewissue.php?issue_no=29

The previous bug was about dark to light controls, but I wasn't aware of any invisible text.

By the way I'm facing similar problem on the Desktop - I'm using black theme on my openSUSE and my controls in the browser are dark gray with black text. This is due to the browser using specified colors by default. You can switch system colors but it gets worse - many sites are setting the background and not the color of the text and it becomes light gray or white on white... So I suspect your problem is due to the same feature/setting.

Not sure. Browsers like Firefox have a default font color setting that is used if the website doesn't specify a color. I assume WebKit has a similar default color setting, and I'd like it to be initialized to the system default text color at least for input fields. Basically, if it uses system native widgets to render an unstyled input field, it should also use the system native font color that goes along with it. Makes sense, no? If a site actually applies any formatting to the input field, it can divert from the system default at that point. This is also a smarter approach than using user CSS, which would always override the site author's formatting.

Getting trigger-happy, I suppose, I also filed two other bugs:

Issue #30 - Ctrl+C to copy and Ctrl+V to paste don't work in the address bar

Issue #31 - Add an option to auto-select address bar contents on widget activation

@Sho - The first is a duplicate, the second is very hard GTKEntry auto-select on focus was ripped off in Maemo, sorry. Also the focus events don't fire on it I lost several days to that. There probably is a way, but I don't know it yet so I suspended it for now. Good to have a bug report though

About the colors - yes, I think I wrote just that above, though you missed something - when you turn on the system colors, the rest of the site breaks, not the input boxes.

Oops, sorry about the dupe. I used "Find on page" to scan the list for "copy" and "ctrl", but forgot "paste", or I would have found it.

Regarding the auto-select: If MicroB can do it, you should be able to, too, right? Strange that the widget doesn't get a QFocusEvent of type QEvent::FocusIn that you can simply hook QLineEdit::selectAll() up to in an event handler, though, to translate into the jargon used by my QBrain.

Let me be more specific:
Here's the Firefox 3 Colors dialog:


Here's what the Google News looks like with system colors enabled:


And that's a big player. My line is this: the problem is in the web sites, not in the browsers. If you set all your colors, your site will be readable despite any settings.

I can check MicroB's sources to check how they do it. Didn't notice that it was possible there, I seldom write in the URL bar

Sorry, this was a later edit to your post, so I'll reply in a separate post now:

I did understand your point that using the system theme colors outright as default background and font colors would break many pages; I'm familiar with the problem, actually. Site authors frequently set a text color but forget to set a background color, so a browser inheriting a black window background color from the system for its document viewport corrupts site layout. I get it.

However, this is a more limited problem. It's about input fields. Somewhere in WebKit(GTK) is code that checks whether an input field is styled or unstyled, and then either uses custom drawing or goes to the system widgets. E.g. if I set "border:1px solid black" on an <input>, WebKit will draw a simple 1px border rectangle instead of a GTK+ widget. In the Google case I cite in the bug report, the website sets up black as default text color in <body>, but applies no other formatting to <input> tags. So WebKit(GTK) probably decides that this is an amount/a type of formatting that can be handled by the system widget and spawns one, asking it to render text in black. I believe that this decision right there is broken, because the widget's *background color* isn't taken from the site (because, well, there usually isn't one set by the author) while the *font color* is, which causes problems like this.

So I ask that it ignores the site's formatting and goes for the system default input field font color in all rendering cases that can satisfied by the system widget. This basically won't really break any pages, because any page that cares to set an unusual (i.e. other than black) font color on <input> will usually also change its background and border properties to a degree causing the GTK+ widget not to be used anyway.

As a KDE developer, I'm more familiar with the KHTML code than with WebKit's, and I expect this is one of the areas where the WebKit codebase diverges the most from KHTML, as KHTML simply directly goes for Qt widgets whereas WebKit has a platform/backend abstraction mechanism. But if the WebKit authors have at all managed to preserve the cleanness and simplicity of the KHTML codebase, the above behavioral change should be fairly simple to pull off.

Yes, probably won't be so hard. I'll check it at some point.