The color theme should not be applied to content rendered by Qt-Webkit, because most pages
on the net don't expect non-white backgroung and therefor are barely useable. I attached a
screenshot of me filling out this form (and there are pages that look a lot worse!).
Created attachment 24965 [details]
(In reply to comment #0)
> The color theme should not be applied to content rendered by Qt-Webkit, because
> most pages
> on the net don't expect non-white backgroung and therefor are barely useable. I
> attached a
> screenshot of me filling out this form (and there are pages that look a lot
> From http://code.google.com/p/arora/issues/detail?id=222
The link to the bug report in the Arora tracker is incorrect. It should be http://code.google.com/p/arora/issues/detail?id=221
In my opinion QtWebKit should obey the color scheme. There would be no problem if QtWebkit would use Text Color from the scheme. Now it takes only Background Color and uses (hard coded?) dark colors for text rendering which leads to poor readability.
Kenneth, didn't you fix this in r44759?
No I did not fix this, but the app can easily overwrite it and I have done exactly that with own browser at INdT.
Carol is looking into making it more generic (respect more of the palette) AFAIK.
(In reply to comment #4)
> Kenneth, didn't you fix this in r44759?
The patch to https://bugs.webkit.org/show_bug.cgi?id=30173 aims at fixing this.
I actually have the patch ready, but noone is willing to review it since it is too big. I am working on making the patch into bits and pieces, but even then, it will be a while until the support will be complete.
Should we mark this bug as a DUP of 30173 ?
(In reply to comment #7)
> Should we mark this bug as a DUP of 30173 ?
The bug itself is not a DUP of 30173.
The issue raised here is different.
30173 is about the author of a page being able to change the color of a control, either foreground or background.
The issue here appears to be about what the default color of controls is if the author of the page does not alter it.
Not reflecting the platform theme colors in the appearance of the controls would be very difficult since WebKit does not provide an implementation for controls such as radio buttons and checkboxes and some QStyle implementations can only render these controls in the default manner.
In conclusion, I believe that the current goal is to reflect theme colors in QtWebkit controls, but reflect them accurately both for foreground and for background.
No test case but easily reproducible.
We discussed that some times time ago. On desktop, devs expect WebKit to follow the style and the palette. As Kenneth said, it can easily be overwritten.
As long as it is actually able to be worked around then it is ok to mark as wontfix. Last I checked it was not possible to work around because sometimes it grabbed the style from QApplication and not the QWebView instance.
(In reply to comment #11)
> As long as it is actually able to be worked around then it is ok to mark as wontfix. Last I checked it was not possible to work around because sometimes it grabbed the style from QApplication and not the QWebView instance.
Ok, lets fix that then. If you see such bug, report it and lets fix that.