403067 - Zooming and resizing window doesn't move scrollbar for hidden tabs

Status: RESOLVED FIXED

(Core :: Layout, defect, P2)

Description

[Daniel Holbert [:dholbert]]

Testing using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007110809 Minefield/3.0b2pre

Steps to reproduce:
 1. Open two tabs with tall content, from the same domain name. For example:
     a. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/
     b. http://ftp.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/
 2. Press Ctrl and + to zoom in
 3. Resize the window horizontally, making it wider.
 4. Switch to the other tab.

RESULTS: other tab's scrollbar is where it was before the window-resize, somewhere in the middle of the window.


If you make the window *skinnier* rather than wider, the other tab's scrollbar ends up partially or fully missing, being somewhere outside the window. (again, in the same place it was before the window-resize)

In both cases, the misplaced scrollbar is still perfectly functional.  You can make it snap back into place with another horizontal window-resize.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot 1: scrollbar in middle of window

> RESULTS: other tab's scrollbar is where it was before the window-resize,
> somewhere in the middle of the window.

See this screenshot for example.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot 2: scrollbar partially outside window

> the other tab's scrollbar
> ends up partially or fully missing, being somewhere outside the window.

See this screenshot for example.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screenshot 3: horizontal scrollbar

Bug occurs for horizontal scrollbars as well.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: screenshot 4: both scrollbars

... and for both scrollbars at the same time.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Tweaking the code added in Bug 227361 is perhaps needed.

Comment 6

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

I don't see this on Mac. Anyone else see it on Mac?

Comment 7

[Daniel Holbert [:dholbert]]

Just tested Mac + Windows with the FF3b1rc3 releases, and can't reproduce on those platforms.

Looks like this is Linux-only.

Comment 8

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

I can actually reproduce this on Mac now that site-specific prefs are working again in my build.

Comment 9

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

Attachment: fix

The problem is that the window size change is deferred for the background tab, and when we switch to the background tab we change its fullZoom before we display it. At that point its prescontext mVisibleArea is stale, but nsPresContext::SetFullZoom takes that and uses it to compute a new size which it passes to nsViewManager::SetWindowDimensions, which overwrites the deferred new size, so the deferred size change is just lost.

This patch makes SetFullZoom get the window dimensions via nsViewManager::GetWindowDimensions instead of mVisibleArea before updating it. Thus any deferred changes are taken into account and not lost. There's a similar bug in PreferencesChanged so I fixed that too.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 290818 [details] [diff] [review]
fix

r+sr=dbaron

Might be good to use consistent variable naming between the two functions -- oldWidth vs. oldWidthDevPixels (and same for Height).

Comment 11

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

ok

Comment 12

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

checked in