Closed Bug 80141 Opened 19 years ago Closed 17 years ago

Anchor moves to wrong position


(Core :: Layout, defect)

Not set





(Reporter: masri, Assigned: attinasi)




(Keywords: testcase)


(2 files, 3 obsolete files)

Platform: PowerBook G3/300/192Mb/30Gb, MacOS X 10.0.2
Build: Fizzilla 20010509

Go to the above URL. Wait until page is completely loaded. Then click in
location bar, hit return. Note that the anchor postion now moves to the right

This bug is being logged specifically for OS X, although this was originally bug
25712 for MacOS.

- Adam
This also shows up with 2001092808 on OS 9.0.4. Almost any page with anchors
will lay out improperly, including Anchors that occur
mixed in with text are typically offset to the left of where they should be,
sometimes overdrawing preceding text.
Blocks: 102998
Ignore that last sentence. I misunderstood the problem being reported with this
bug. I'll check whether there's another that describes the behavior mentioned.
Note, however, that the behavior described in the original report does occur on
Mac OS 9.0.4.
not a table specific bug, reassigning to core owner.
Assignee: karnaze → attinasi
Including a reduced test case
Attached file Slightly modified test that does work (obsolete) —
This test is exactly the same except that it includes HR elements after the
anchor name element.
Platform/OS -> All/All. I am seeing the problem on Windows too with a tip of 
the trunk.

Here is a page with several anchored links:
Visit the page and click "%att-common" for example.
Nav4.x jumps to where expected flawlessly while mozilla misses the target.
The same scenario arises with other anchors on that page.
OS: MacOS X → All
Hardware: Macintosh → All
Just a guess, is the scrollbar having any effect here? What is curious is that
when the page is already laid out, then clicking on anchors from within the page
seems to work as expected. For example, targets are ok when visiting this URL
and clicking from therein:

But when referenced from an external file like the link I gave above, targets
are not positioned as expected.
Target Milestone: --- → mozilla1.0.1
MacOS X 10.1.2
Build 2002020608
I guess its been awhile, this seems to work fine for me now.
Per comments from Kevin G. and my testing of 098 marking WORKSFORME
Closed: 18 years ago
Resolution: --- → WORKSFORME
In build 2002020903, this is still happening.

- Adam
Resolution: WORKSFORME → ---
Sorry for the premature WORKSFORME - the MathML page links do work but the link for the specified test URL does not
This bug is on the list of Mac bugs identified as significant enough to merit
fixing for MachV - adding nsbeta1 keyword.
Keywords: nsbeta1
Bulk moving all nsbeta1 nominations to Moz1.1.  If the nomination is approved it
will be marked nsbeta1+ and moved to the Mozilla1.0 milestone.
Target Milestone: mozilla1.0.1 → mozilla1.1
Marking nsbeta1-.  The problem is the images come in after we have scrolled to
the coorect location and they don't have a width and height specified. In most
cases images have a width and height specified so this isn't an issue.
Note: IE 6 behaves exactly the same as Mozilla. It scrolls to the wrong location
when the images come in. 
Keywords: nsbeta1nsbeta1-
Confirming that IE 5.1 on Mac OS X exhibits the same behavior.  Based on this
and that it could be considered bad HTML (no width and height specified on the
image) I'd agree with nsbeta1- and will remove it as a blocker for 102998.
No longer blocks: 102998
I see the same behavior on a page which doesn't have anything to do with images
or MacOS X.  Go to this link:

and click on one of the links.  Wrong spot.  Put the focus in the URL bar and
hit return.  Right spot.
Re-nominating. This doesn't need images to happen. Looks like the scrolling may
also happen before tables and other textual data are completely laid out. Makes
anchors pretty useless in many cases. This seems to happen almost always when
the connection is slow or the data is generated dynamically and it doesn't come
in fast enough. 
Keywords: nsbeta1-nsbeta1
QA Contact: petersen → praveenqa
Was able to get the bug on W2k with build 2002-10-21-08-trunk/
Additional comments:
once you are able to reproduce the bug using the testcase or otherwise, clear
the cache to be able to repeat it
Attachment #59926 - Attachment is obsolete: true
Attachment #59929 - Attachment is obsolete: true
Attachment #59931 - Attachment is obsolete: true
once you are able to reproduce the bug using the testcase or otherwise, clear
the cache to be able to repeat it
Keywords: testcase
Keywords: nsbeta1nsbeta1-
I can approve this behavior with mozilla 1.1 on windows. The problem is
reproducable with a large html page, which is generated dynamically. 
The data isn't come in fast enough. Once loaded, going to the url-bar and
pressing return will jump to the correct position.
See comment #19
This is basically bug 60307
Depends on: 60307
Re: comment #24
> This is basically bug 60307

I disagree. I have seen this problem with Moz for a while now. I have a script
that grabs a bunch of comics and puts them onto a HTML page. I have links for
the next and previous days that use anchors to correctly center the display.
Without image sizes, the anchors would not work correctly (until the images were
in cache, at which time reloading the page worked fine). Putting the image sizes
into the HTML makes the anchors work properly.

To me, that indicates that Moz is calculating the anchor positions before it's
loaded the images. Which is different to scrolling the display as each image loads.
This is a simple html page showing the problem, or at least one aspect of it.
First there's a table, then some filler stuff, an anchor and some more stuff.
The table is hidden in onload handler and causes the position to change
incorrectly. IE handles it correctly, if anyone cares.
QA Contact: praveenqa → dsirnapalli
Comment 25 is _exactly_ consistent with bug 60307 -- there is no "scrolling",
just resizing as the image sized become known. If they are set, there is no

Marking duplicate, since it's silly to have multiple open bugs on this one problem.

*** This bug has been marked as a duplicate of 60307 ***
Closed: 18 years ago17 years ago
Resolution: --- → DUPLICATE
No longer depends on: 60307
You need to log in before you can comment on or make changes to this bug.