510753 - [Windows] page loaded in the background first displays in normal size, then the site-specific text zoom is applied, causing the page to jump

Status: RESOLVED INVALID

(Firefox :: General, defect, P3)

Description

[Sylvain Pasche]

+++ This bug was initially created as a clone of Bug #386835 +++

A page loaded in the background first displays in normal size when switched to it.
Then the site-specific text zoom is applied. This causes the whole page to jump.

STR:
1. Visit a site like http://en.wikipedia.org/wiki/Main_Page.
2. Set text-zoom to larger or smaller than normal by pressing Ctrl + or Ctrl -.
3. Load a couple of pages from the same site in the background by middle-clicking e.g.
  http://en.wikipedia.org/wiki/Mozilla
  http://en.wikipedia.org/wiki/Mozilla_Firefox
  http://en.wikipedia.org/wiki/Page_zooming
4. Switch to the background tabs.
5. Optionally repeat steps 2, then 4.

Actual result:
After step 4, the page displays for a split-second (but long enough that you're able to start reading) in normal text-zoom, then jumps to the site-specific text-zoom.
After step 4, the page displays for a split-second in the *previous* displayed text-zoom, then jumps to the *new* site-specific text-zoom.

Expected result:
The page displays in the correct text-zoom from the beginning.

Comment 1

[Dave Townsend [:mossop]]

What version of Firefox are you testing with?

Comment 2

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20090815 Minefield/3.7a1pre

WFM, I see only the correct font-size, no jump.

Comment 3

[Dave Townsend [:mossop]]

We also have automated tests verifying that this problem doesn't happen on a clean Firefox so I suspect an extension or something might be playing a part here.

Comment 4

[Sylvain Pasche]

Yeah, that's strange. I can reproduce with 3.5 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2) or with trunk (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090816 Minefield/3.7a1pre) on XP, Vista or Win7 using a clean profile.

Comment 5

[Alice0775 White]

Because nsIContentPrefObserver (FullZoom.onContentPrefSet and FullZoom.onContentPrefRemoved) changes the zoom level only gBrowser.currentURI.


To fix this bug,The observer checks URI of the tab of all backgrounds and must change zoom rate.
However, in such a case it will become the considerably HEAVY processing.

Comment 6

[Dave Townsend [:mossop]]

(In reply to comment #5)
> Because nsIContentPrefObserver (FullZoom.onContentPrefSet and
> FullZoom.onContentPrefRemoved) changes the zoom level only gBrowser.currentURI.
> 
> 
> To fix this bug,The observer checks URI of the tab of all backgrounds and must
> change zoom rate.
> However, in such a case it will become the considerably HEAVY processing.

That is true if you change the zoom of a tab when there are already multiple tabs for the same site open. But that isn't what this bug is about according to comment 0. This bug is about new tabs loaded after the zoom level has already been set.

Comment 7

[Alice0775 White]

(In reply to comment #6)
> This bug is about new tabs loaded after the zoom level has already
> been set.

OK,
So, I can not reproduce the issue.

Comment 8

[Sylvain Pasche]

oh wait, I was changing the zoom level after having loaded the background tabs :-/ Damn, I should learn how to follow the STR correctly, sorry for that.

There is no issue if you change the zoom level before opening the background tabs.

However, there is still a platform difference: If you change the zoom level after having loaded the background tabs on Mac+Linux, when you switch to the background tab there is no visual glitch: the zoom level appears to have been already set correctly on the first paint.
However on Windows you can see the old zoom level for a moment.

Maybe I should open a new bug for that to avoid confusion (if that's worth fixing because of the potential performance issue).

Comment 9

[Dave Townsend [:mossop]]

OSX is certainly waiting until the tab switch before changing the zoom level, but it may be that windows is repainting too quickly so seeing the old and new zoom levels or something.

But yes I'd suggest we close out this bug and you open a fresh one with correct STR to save confusion.

Comment 10

[Sylvain Pasche]

Filed bug 510799.