221938 - anchor links do not point to correct location on target page if onload event removes content

Status: NEW

(Core :: Layout, defect)

Description

[mcohen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1

If you go to http://members.cox.net/mcohen25/mozbug/bio.htm and click on one of
the links in the second paragraph just after where it says "They include," (3rd
sentence) you will see that the links send you to the wrong location within in
the "services" page, about a paragraph lower on the page than the anchor the
link actually targets.  ("The anchor," in this case being an <h2> with its id
attribute set.)

This occurs because there is some javascript called by the onload event on the
services page that removes some content further up on the page when it loads (by
setting a certain div's CSS display:none).  So it seems that Mozilla is setting
the viewport *before* running the onload event, then the onload event runs and
removes the specified content, pulling the rest of the content upwards. The
result is that the viewport is no longer aligned to the correct anchor on the
page.  IE seems to do things in the reverse order (i.e., it runs onload, *then*
sets the viewport to the correct anchor) because it points to the expected
location in this example.

I'm no fan of IE, but in this case it seems that their approach is more logical.
 For this specific page, I can pretty easily work around the problem by not
using javascript to hide the content, but it seems to me that there would be
many times when you might want to add/remove/change content using onload, and
based on this example, it seems that trying to do that would always break anchor
links (that are pointing in from another page) in Mozilla.  (Anchor links that
point to a location within the same page are unaffected, of course, because
onload will have run and done its content-changing before anyone has a chance to
click the links.)

So I don't know if this necessarily qualifies as "bug" -- the order of events
may have been intentional.  Still, as a developer, I would prefer to see Mozilla
execute any onload code *before* setting the viewport to a certain anchor.  That
would offer more flexibility in creating dynamic pages, and ensure that anchor
links always work as expected in conditions like this.

Thank you, and keep up the great work!

-Mac

Reproducible: Always

Steps to Reproduce:
1. Go to http://members.cox.net/mcohen25/mozbug/bio.htm
2. click on one of the links just after where it says "They include," (in the
3rd sentence of the 2nd paragraph)
Actual Results:  
Mozilla's viewport is aligned about a paragraph below the targeted anchor on the
new page, instead of directly on the targeted anchor.

Expected Results:  
Set the viewport directly on the targeted anchor, as per the usual behavior of
anchor links.

Comment 1

[Boris Zbarsky [:bzbarsky]]

We move to the anchor as soon as we can -- not only before onload, but also
before the page has finished parsing.  This way, the user is taken to the place
they wanted as soon as possible...

Now arguably we should be maintaining our position at the anchor when content
moves around...  See dependencies of bug 43114

Comment 2

[mcohen]

Thanks, I took a look at those dependencies and I get the gist of the problem now.

Let me just mention then that, as a designer, I favor the "align viewport to an
object in the upper left corner when things move" approach over the "align
viewport to a certain % offset" approach.  It seems to me that there's all kinds
of dynamic content that will break the % approach, whereas the object approach
will keep things about as consistent as one could possibly hope.

That said, I'm no app programmer, so whatever solution you all can come up with
is fabulous and will be received with much gratitude. :)

Comment 3

[Alex Hirzel]

Present in Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031208

Confirming as it seems to be universally reproducable.