1216248 - Events over caption buttons do not cause repaint

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[:Felipe Gomes (needinfo for replies!)]

On OSX, events over the caption buttons are not triggering a repaint, and the buttons remain in their unhovered state. The mouse movement is a bit inconsistent and sometimes you can easily see the bug, sometimes not, but there's one condition that makes it easier to see.

STR:
- It is easier to see this in a clean profile with a window with only a single tab where there will be less other things causing refreshes
- Make sure that focus is not in a text field as that will blink the text caret
- Move the mouse over the green button (Maximize/Fullscreen)
- Hold down the Alt/Option key, which in OSX will change the button between the "Maximize" and the "Go fullscreen" modes

The button state should update immediately, but it doesn't. You have to move the mouse out of it (e.g. to the yellow button) while holding Option to see it updating.

If there's a load spinner in one of the tabs the button will update immediately. Also, if you focus the URL bar, you can see that the button will update in sync with the caret blinking.


Using mozregression, I got: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e7e69cc8c07b&tochange=9b902b7669ae

Comment 1

[Markus Stange [:mstange]]

It looks like turning layers.acceleration.draw-fps on makes this bug disappear, and that's why I never saw it. Oh dear.

Comment 2

[Markus Stange [:mstange]]

I bet it's this changeset: https://hg.mozilla.org/mozilla-central/rev/2d10765f4a82

Comment 3

[Markus Stange [:mstange]]

nsChildView calls ShadowLayerForwarder::WindowOverlayChanged, which causes that to go ahead with sending a transaction without any ops to the compositor, but it doesn't actually tell the compositor that the window overlay changed.

Do we need a new CompositableOperation? Or should we call an IPDL method on the compositor outside of the transaction?

Comment 4

[Matt Woodrow (:mattwoodrow)]

I think adding a new CompositableOp makes the most sense for this.

Comment 5

[Markus Stange [:mstange]]

Attachment: MozReview Request: Bug 1216248 - Recomposite when the window overlay changes. r?mattwoodrow

Bug 1216248 - Recomposite when the window overlay changes. r?mattwoodrow

Comment 6

[Matt Woodrow (:mattwoodrow)]

Comment on attachment 8676291 [details]
MozReview Request: Bug 1216248 - Recomposite when the window overlay changes. r?mattwoodrow

https://reviewboard.mozilla.org/r/22643/#review20191

Comment 7

[Markus Stange [:mstange]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a4ae2661aef7

Comment 8

[Markus Stange [:mstange]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0d8f147de68d

Comment 9

[Markus Stange [:mstange]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/58593839ebcedb976068fca5901af41cf48912d9
Bug 1216248 - Recomposite when the window overlay changes. r=mattwoodrow

Comment 10

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/58593839ebce

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/58593839ebce