480175 - Incorrect named anchor scrolling position when stylesheet linked via DOM manipulation

Status: NEW

(Core :: Layout, defect)

Description

[will.lynn]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6

In the demo page http://members.optusnet.com.au/w.lynn/ffbug/

The two pages linked via named anchors are identical except that the main.css file is referenced with a static LINK tag in the first and added using JavaScript via the DOM in the second page. The named anchor doesn't work in the second page if you visit it from the first page, but will work if you visit it from inside the second page when it is already loaded.

Tested in FF 2 and FF 3.06. All the html and CSS validates. The scrolling position for both pages works fine in IE/Opera/Safari.

Reproducible: Always

Steps to Reproduce:
1. Visit http://members.optusnet.com.au/w.lynn/ffbug/
2. Click on the link to page 2. You will be scrolled to the bottom of the page instead of the position of the named anchor.
Actual Results:  
Firefox does not scroll to the correct position.

Expected Results:  
Firefox should scroll to the correct position regardless of how the CSS is referenced. Other browsers do.

This seems to occur when there is a height:[number]px element and display:none although I have not determined all instances where this happens. This is not affected by very simple layouts.

If you browse to page2.html and then go to the anchor, Firefox scrolls to the correct anchor position.

Tested on Windows 2000, XP and Server 2003 on FF 2 and 3.06 versions.

Comment 1

[will.lynn]

"This is not affected by very simple layouts." - sorry this is ambiguous, I meant that simple CSS layouts do not cause a problem with the anchor scrolling position.

Comment 2

[Kurt Weinschenker]

Also happens with a recent (2.0b3pre (1.9.0.8pre 2009022319)) build of Camino running under Tiger-PPC (Mac OS X 10.4.11).  Have not checked this with Leopard (Mac OS X 10.5.x) or Intel Mac.

Comment 3

[Jesse Ruderman]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090225 Minefield/3.2a1pre

I can reproduce this bug 80% of the time.

Maybe Firefox isn't taking the stylesheet load into account when deciding whether the page is "done" enough to do the final anchor scroll?  It is added by an inline script, so I'd expect it to be taken into account.

The testcase is good, but it would be even better if you could make one that uses http://software.hixie.ch/utilities/cgi/test-tools/delayed-file.pl and attach it so we can be sure it doesn't get lost.

Comment 4

[Boris Zbarsky [:bzbarsky]]

The anchor scroll happens on parse completion, not onload.  You get the same issue with an anchor below some slow-loading images, and we have existing bugs on that...

Comment 5

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

such as bug 43114, bug 103279, etc.

Comment 6

[will.lynn]

Apologies if this is a duplicate. I did search for a similar bug before I reported this but I'm not too familiar with the internal workings of FF (such as anchor scroll happening on parse completion).

Comment 7

[Jesse Ruderman]

And I guess the reason this doesn't happen in the non-script case is that the stylesheet load blocks layout?

Comment 8

[Boris Zbarsky [:bzbarsky]]

Will, not a problem.  It's not obvious that this is a duplicate by any means, unless you know how the code works!

Comment 7 is right.