Closed Bug 932055 Opened 6 years ago Closed 6 years ago

Overlay buttons flicker or disappear when panning while zoomed

Categories

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

26 Branch
x86_64
Windows 8.1
defect

Tracking

()

RESOLVED DUPLICATE of bug 951467
Tracking Status
firefox28 --- affected
firefox29 --- affected

People

(Reporter: jimm, Unassigned)

References

Details

Attachments

(4 files, 1 obsolete file)

STR:

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

result: the overlay browser buttons will flicker or disappear.
No longer blocks: 915724
Blocks: metro-apzc
Taking a look.
Assignee: nobody → spohl.mozilla.bugs
Status: NEW → ASSIGNED
Whiteboard: [block28] → [block28] feature=defect c=tbd u=tbd p=3
Whiteboard: [block28] feature=defect c=tbd u=tbd p=3 → [block28]
See Also: → 941003
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
Blocks: 902505
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.
Whiteboard: [block28] → [beta28][gfx]
Blocks: 941003
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
Blocks: metrov1backlog, metrov1omtc&apzc
No longer blocks: metro-apzc
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.
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 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!
Attachment #8343232 - Flags: feedback?(roc)
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?
Blocks: metrov1it21
No longer blocks: metrov1backlog
Priority: -- → P1
QA Contact: jbecerra
Whiteboard: [beta28][gfx] → [beta28][gfx] p=8
Attached file 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.
Attachment #8343232 - Attachment is obsolete: true
Attachment #8343232 - Flags: feedback?(roc)
Flags: needinfo?(roc)
Attached image before.jpg
Before zooming (with layers.draw-borders set to true).
Attached image after.jpg
After pinch-zooming and releasing screen (both buttons no longer visible).
(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.
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.
(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.
Flags: needinfo?(roc)
For the sake of QA can we get reduced test case or a URL we can test?
Attached file 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.
(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
Not much (if any) progress to report, so I'll see if I can be more useful with some of the other outstanding blockers.
Assignee: spohl.mozilla.bugs → nobody
Status: ASSIGNED → NEW
Blocks: metrov1backlog
No longer blocks: metrov1it21
QA Contact: jbecerra
Whiteboard: [beta28][gfx] p=8 → [beta28][gfx]
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 951467
No longer blocks: metrov1backlog
Whiteboard: [beta28][gfx]
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.