Bug 112688 – [Qt] QStyle: Invalid rendering of button elements (missing enabled state)

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[David Rosca]

Created attachment 193806 [details]
Added State_Enabled as default

There is an issue with rendering buttons, comboboxes, checkboxes (and I think also other elements) with QStyle.
QStyle::State_Enabled is never set, so resulting buttons looks like disabled (except color of text).

I'm using QGtkStyle, but I believe this issue is not related to it.

Screenshots before/after the patch: https://dl.dropbox.com/u/42835431/qtwebkit/buttons-rendering.png

In the attached patch, QStyleFacade::State_Enabled is set as a default state, which fixes this issue.

[David Rosca]

Created attachment 193807 [details]
Testing page

[Jocelyn Turcotte]

That might not really be useful information I'm seeing this bug with the GTK style, but not the fusion style.

[David Rosca]

The same issue is also reproducible on Windows Vista style.
I think the main problem here is that all elements are painted without State_Enabled flag set, even if they actually are enabled. 
It's possible that it makes no difference with Fusion style (I didn't test it with Qt 5), but it shouldn't break it.

[Pierre Rossi]

(In reply to comment #0)
> Created an attachment (id=193806) [details]
> Added State_Enabled as default
> 
> There is an issue with rendering buttons, comboboxes, checkboxes (and I think also other elements) with QStyle.
> QStyle::State_Enabled is never set, so resulting buttons looks like disabled (except color of text).
> 
> I'm using QGtkStyle, but I believe this issue is not related to it.
> 
> Screenshots before/after the patch: https://dl.dropbox.com/u/42835431/qtwebkit/buttons-rendering.png
> 
> In the attached patch, QStyleFacade::State_Enabled is set as a default state, which fixes this issue.

Thanks for this patch. I think it would be nice to have for the sake of correctness.
Could you just resubmit it with a Changelog entry so that it follows the guidelines please ? More reading here: http://www.webkit.org/coding/contributing.html

(In reply to comment #2)
> That might not really be useful information I'm seeing this bug with the GTK style, but not the fusion style.

I suspect it's because most Qt styles don't base the button look on that state (only the text color is affected).

[David Rosca]

Created attachment 193827 [details]
Patch with changelog

[David Rosca]

Created attachment 193828 [details]
Patch with changelog 2

[Pierre Rossi]

Comment on attachment 193828 [details]
Patch with changelog 2

Looks reasonable to me. The other option was to add an else statement to the if (!isEnabled(o)) a bit below... I guess it's a matter of taste.

[WebKit Review Bot]

Comment on attachment 193828 [details]
Patch with changelog 2

Clearing flags on attachment: 193828

Committed r146205: <http://trac.webkit.org/changeset/146205>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Simon Hausmann]

*** Bug 116804 has been marked as a duplicate of this bug. ***

[Stephen]

Thanks for the fixing the bug, Simon. However, that's not the end of the story when it comes to the rendering of the controls. After I apply this patch, the control now appears enabled. However, both the checkbox and radio buttons are not properly rendered. Here is a test page: http://www.slimbrowser.net/testpages/testform.htm . In this page, the checkbox appears not checked even after a mouse click. If I hover the mouse on the checkbox, the radio becomes checked. When I hover the mouse on the radio button and then move the mouse button away, it looks like a stretched radio buttom bitmap is drawn in the background on the first edit box in the same form. I am using the Windows Vista style on Windows 7 for this test. 

I did some tracing myself here. It appears there is problem with the code inside this function in qwindowsvistastyle.cpp.

void QWindowsVistaStyle::drawPrimitive(PrimitiveElement element, const QStyleOption *option,QPainter *painter, const QWidget *widget) const

There seems to be issues related to the transition animation drawing. Even if there is no state change, the oldState and state are never the same. If I disable the transition animation, the rendering is ok for Windows vista style. 

If I switch to the Windows XP style, the edit box is rendered without border. 

I can provide more details and clues if you want. But I guess you might push this bug towards the QT guys since it's already outside the qtwebkit layer. 

David, can you produce the same issue?

[Simon Hausmann]

(In reply to comment #11)
> Thanks for the fixing the bug, Simon. However, that's not the end of the story when it comes to the rendering of the controls. After I apply this patch, the control now appears enabled. However, both the checkbox and radio buttons are not properly rendered. Here is a test page: http://www.slimbrowser.net/testpages/testform.htm . In this page, the checkbox appears not checked even after a mouse click. If I hover the mouse on the checkbox, the radio becomes checked. When I hover the mouse on the radio button and then move the mouse button away, it looks like a stretched radio buttom bitmap is drawn in the background on the first edit box in the same form. I am using the Windows Vista style on Windows 7 for this test. 
> 
> I did some tracing myself here. It appears there is problem with the code inside this function in qwindowsvistastyle.cpp.
> 
> void QWindowsVistaStyle::drawPrimitive(PrimitiveElement element, const QStyleOption *option,QPainter *painter, const QWidget *widget) const
> 
> There seems to be issues related to the transition animation drawing. Even if there is no state change, the oldState and state are never the same. If I disable the transition animation, the rendering is ok for Windows vista style. 
> 
> If I switch to the Windows XP style, the edit box is rendered without border. 
> 
> I can provide more details and clues if you want. But I guess you might push this bug towards the QT guys since it's already outside the qtwebkit layer. 

Yes, if you can isolate this down to being a Qt issue, we should take it to the Qt project bug tracker.


Pierre, can you think of anything from the WebKit side that would affect the animations/transition? Is the style perhaps issuing updates that we're not handling?

[Simon Hausmann]

(In reply to comment #11)
> Thanks for the fixing the bug, Simon. However, that's not the end of the story when it comes to the rendering of the controls. After I apply this patch, the control now appears enabled. However, both the checkbox and radio buttons are not properly rendered. Here is a test page: http://www.slimbrowser.net/testpages/testform.htm . In this page, the checkbox appears not checked even after a mouse click. If I hover the mouse on the checkbox, the radio becomes checked. When I hover the mouse on the radio button and then move the mouse button away, it looks like a stretched radio buttom bitmap is drawn in the background on the first edit box in the same form. I am using the Windows Vista style on Windows 7 for this test. 

FWIW, this should be tracked in a different bug then. This bug (as the title says) is about the incorrect rendering as disabled state even though it's enabled, while the issue you're describing seems different.