932055 - Overlay buttons flicker or disappear when panning while zoomed

Status: RESOLVED DUPLICATE of bug 951467

(Core :: Graphics: Layers, defect, P1)

Description

[Jim Mathies [:jimm]]

STR:

1) load any page
2) zoom in a bit
3) pan around

result: the overlay browser buttons will flicker or disappear.

Comment 1

[Stephen A Pohl [:spohl]]

Taking a look.

Comment 2

[Stephen A Pohl [:spohl]]

I haven't made much progress yet, but after commenting out browser.setWindowSize [1], the overlay buttons no longer disappear. This was introduced in bug 902505 to fix the fact that content remained blurry and didn't get repainted after a zoom.

I've also noticed that since landing bug 902505, scrollbars no longer display when using the trackpad to scroll when the page is zoomed in. 

[1] http://mxr.mozilla.org/mozilla-central/source/browser/metro/base/content/browser.js#1320

Comment 3

[Stephen A Pohl [:spohl]]

Slowly inching closer to what's going on here. I'm writing this down mostly for my own record:

1. After zooming in on the page, AsyncPanZoomController::OnScaleEnd calls RequestContentRepaint.
2. The RequestContentRepaintEvent calls APZCCallbackHelper::UpdateRootFrame.

The overlay buttons remain visible for as long as we *think* they are visible on screen, but we're forgetting that they're *always* on screen. It's probably easier to imagine this way: If we assumed for a second that the buttons were fixed with the content and would scale along with the content, the layers for the buttons would no longer be shown when they moved off the screen. Somewhere we seem to compute the visibility of a layer but are forgetting that the buttons aren't fixed with the content, nor scale with the content and that we should always show them.

Comment 4

[Stephen A Pohl [:spohl]]

By commenting out "top: 50%" for overlay buttons in browser.css [1], this problem goes away. I'm not sure yet if this is the problem (i.e. we shouldn't be using 'top' in this situation), or if it's just exposing it. The buttons are obviously not positioned correctly without it.

I've tried finding related bugs in the bugbase but haven't found anything that quite matches this yet.

[1] http://mxr.mozilla.org/mozilla-central/source/browser/metro/theme/browser.css#329

Comment 5

[Jim Mathies [:jimm]]

Per discussions between marcom and milan, we're requesting tracking on the remaining "big issues" related to apzc for metrofx, which is riding the 28 train. We expect these will get fixed during the long aurora train ride.

This bug appears to be graphic related, when panning zoomed content ui elements that overlay content flicker and disappear.

Comment 6

[Stephen A Pohl [:spohl]]

Attachment: dump generated with MOZ_DUMP_PAINT_LIST

This is a dump generated by setting MOZ_DUMP_PAINT_LIST in the environment. I've added text to the divs for the overlay buttons in browser.xul to identify them more easily in the dump. The "back" button is labelled "LEFT BUTTON" and the "new tab" button is labelled "RIGHT BUTTON". Metro Firefox was started, then attached to with Visual Studio (so the dump will not contain info from startup). From the start page, a local html file was loaded. At this point, both buttons display correctly. I've then zoomed in on the page via pinch-to-zoom. After releasing the screen, both buttons were no longer visible.

Unfortunately, we don't seem to be able to dump our painting to a file via MOZ_DUMP_PAINT_TO_FILE in Metro Firefox because we rely on OMTC [1].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=737319#c1

Comment 7

[Stephen A Pohl [:spohl]]

Comment on attachment 8343232 [details]
dump generated with MOZ_DUMP_PAINT_LIST

Robert, would you be able to take a quick look at this dump? Is there anything obvious that jumps out at you? Are there any other layout debugging tricks that you could recommend? Thank you!

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Could this be related to bug 945634? Is it a regression from bug 919144?

In your paint list dump, it doesn't look like LEFT BUTTON is missing from any of the display lists that contain chrome content. Is that right?

Comment 9

[Stephen A Pohl [:spohl]]

Attachment: dump1.txt

I was confident that both buttons were no longer visible at the end of the previous dump, but I've created a second dump just to make sure. Both buttons were definitely no longer visible once the screen was released in this one. I'll be attaching before and after screenshots shortly.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #8)
> Could this be related to bug 945634? Is it a regression from bug 919144?

Looking into this.

Comment 10

[Stephen A Pohl [:spohl]]

Attachment: before.jpg

Before zooming (with layers.draw-borders set to true).

Comment 11

[Stephen A Pohl [:spohl]]

Attachment: after.jpg

After pinch-zooming and releasing screen (both buttons no longer visible).

Comment 12

[Jim Mathies [:jimm]]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #8)
> Could this be related to bug 945634? Is it a regression from bug 919144?

Bug 919144 landed 11/18, this was filed 10/28, so doesn't look like it.

Comment 13

[Stephen A Pohl [:spohl]]

Interesting: the behavior in bug 945634 seems to be the opposite of the problem here. During zooming (i.e. while the fingers touch the screen), the overlay buttons in this bug are displayed correctly while the boxes in bug 945634 are shifting incorrectly (the bug mentions that the transform is applied twice). Once the screen is released, the overlay buttons in this bug disappear, while the boxes in bug 945634 snap back to their correct position.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Stephen Pohl [:spohl] from comment #9)
> Created attachment 8344743 [details]
> dump1.txt
> 
> I was confident that both buttons were no longer visible at the end of the
> previous dump, but I've created a second dump just to make sure. Both
> buttons were definitely no longer visible once the screen was released in
> this one. I'll be attaching before and after screenshots shortly.

The display list looks correct. It seems like an APZC bug.

Comment 15

[Benjamin Kerensa [:bkerensa]]

For the sake of QA can we get reduced test case or a URL we can test?

Comment 16

[Stephen A Pohl [:spohl]]

Attachment: test case

The issue basically reproduces on any page when zoomed in. Here is a simple html file that I've been using to reproduce the issue locally. Zoom in and you'll notice that the right button disappears when the screen is released. If zoomed in almost to the maximum, the left button will disappear as well. When panning, the overlay buttons will appear/disappear quickly.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Did bug 945634 make a difference?

Comment 18

[Stephen A Pohl [:spohl]]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #17)
> Did bug 945634 make a difference?

No, unfortunately not.

I've noticed that by skipping the call to WrapDisplayList for aLists.BorderBackground[1], the buttons no longer disappear when zooming and/or panning. However, the background also no longer extends across the whole screen, so I'm not sure yet if this is meaningful.

[1] http://mxr.mozilla.org/mozilla-central/source/layout/base/nsDisplayList.cpp#2992

Comment 19

[Stephen A Pohl [:spohl]]

Not much (if any) progress to report, so I'll see if I can be more useful with some of the other outstanding blockers.