406859 - zoom acts on multiple tabs in concert, elicits a bucket of jump-scroll complaints

Status: RESOLVED DUPLICATE of bug 419612

(Firefox :: General, defect)

Description

[Allan]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1

I discovered this dragged a tab from my right window on top of a tab on my left window, replacing that tab's contents.  When next I pressed zoom *BOTH* displayed tabs zoomed in tandem.  I thought this might be a bug in tab move, where the move tab remained linked to the source tab.  Upon more investigation, I discovered that for all tabs with the same base URL, zoom acts in concert.  It next occurred to me that this might be a design feature.  But then I noticed that the rule for concurrent zoom is peculiar.  At the moment, I'm viewing MediaWiki pages.  I have one tab open to a redirect page and another open directly to the target page.  Tabs display the same contents, but URLs are quite distinct.  Tandem zoom occurs.  This also occurs if I clink an index link internal to one of the tabs with #target appended to the URL.  

Even if that is a desired behaviour, and I'm not certain it should be, I've noticed something about how the zoom positions page content that is certainly a huge aggravation.  I upgraded directly from 1.5.x so I missed the whole 2.x experience.  I did notice that when I scroll a page manually, subsequent zoom operations have a fixed point at the top of the screen (the line at the top of the screen mostly stays put).  However, when I click a section name on my MediaWiki page (e.g. to go directly to the "See also" subsection) with a URL of the form wiki/article#see_also that the fixed point for zoom is way off in left field.  My entire screen contents change every time I click zoom.  

If the tandem zoom is a desired feature, much more care needs to be taken that the fixed point for zoom for each display instance remains *within* the visual region, because if you had a table from one page nicely centered in one view, then resized the view to that page in another tab, you wouldn't want to return to table tab not to find anything there you recognized.  You might not even recall the purpose of that tab was to view a table in small magnification.  

It was always horrendous that zoom didn't maintain fixed points better in the first place.  Back in the day when I wrote word processing code for CJK word processors, I used to call the affine fixed point the "pin".  A function like search which can "jump" the window had special rules: if the new search target could be displayed without moving the view, we tried to do that.  If not, if both the previous cursor item and the new cursor item could be accommodated in the same view, we tried to do that.  If the new item was a jump view with no possible overlap of the previous view, we canceled any prevailing horizontal scroll.  Then attempted to set the pin 1/3 of the way down the primary rendering axis (left margin, for English rendering).  If the display item was offscreen as a result, then horizontal scroll would also be supplied if that fixed the problem.  

Yuck.  I see that searching F/B "the" on a long page yields most of my cursor placements in the top or bottom line of text on the screen.  Terribly unkind.  For example, I might not actually be search for "findme", but a fragment of text which I recall as being very near-to "findme".  What an immense hassle under the current regime.  Firefox *really* should work harder to supply prior/post context lines after jump scrolls.  


Reproducible: Always

Steps to Reproduce:
1. duplicate a tab by window-to-window tab copy 
2. press zoom 

Actual Results:  
multiple tabs zoom in concert 


Expected Results:  
1. only a single tab zooms at a time 
-OR- 
2. multiple tabs zoom in concert, with carefully managed fixed points (pin), so that implicitly zoomed tabs don't suffer a zoom-induced jump scroll

Comment 1

[j]

this happens with any mix of tabs, not just duplicates. also, when you go to a new tab, the new zoom is applied at that time, causing a visible page jump.

Comment 2

[Mark]

In Firefox 3, Beta 5, the zoom affects ALL tabs, even those unrelated to the sites already open in other tabs.

Comment 3

[Elmar Ludwig]

Please report only one issue per bug report. This bug basically covers:

bug 419612 - pref to not update site-specific zoom for existing background tabs
bug 386835 – page loaded in the background first displays in normal size, then the site-specific text zoom is applied, causing the page to jump
bug 355229 – Leave some room when scrolling to named anchors

I'm going to mark this as a duplicate of bug 419612, since that seems to be the main issue here.