Bug 22123 – [Qt] QtWebKit should not apply color scheme to QWebPage

• Component: Layout and Rendering
• Status: RESOLVED WONTFIX

[Benjamin Meyer]

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!).

From http://code.google.com/p/arora/issues/detail?id=222

[Benjamin Meyer]

Created attachment 24965 [details]
color issue

[Leonardo Aidos]

(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
> worse!).
> 
> 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

[Antti Kaijanmäki]

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.

From https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/407340

[Simon Hausmann]

Kenneth, didn't you fix this in r44759?

[Kenneth Rohde Christiansen]

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.

[Carol Szabo]

(In reply to comment #4)
> Kenneth, didn't you fix this in r44759?

Simon,
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.

[Laszlo Gombos]

Should we mark this bug as a DUP of 30173 ?

[Carol Szabo]

(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.
In off-line and on-line discussions it appears to me that a significant opinion current has been built in the QtWebkit contributors' community, advocating allowing authors to change the default colors as much as possible even if the shape of the control is going to be degraded, and reflecting the color and shape of the native controls both in the default CSS style attributes available to inspection by Javascript running in the browser and in the default appearance of the controls.
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.

[Jocelyn Turcotte]

No test case but easily reproducible.

[Benjamin Poulain]

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.

[Benjamin Meyer]

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.

[Benjamin Poulain]

(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.