80141 - Anchor moves to wrong position

Status: RESOLVED DUPLICATE of bug 60307

(Core :: Layout, defect)

Description

[Adam Masri]

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

http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-121.html#HEADING121-40

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
location.

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

- Adam

Comment 1

[jsp]

This also shows up with 2001092808 on OS 9.0.4. Almost any page with anchors
will lay out improperly, including http://www.mozilla.org. Anchors that occur
mixed in with text are typically offset to the left of where they should be,
sometimes overdrawing preceding text.

Comment 2

[jsp]

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.

Comment 3

[anthonyd]

not a table specific bug, reassigning to core owner.

Comment 4

[Chris Petersen]

Including a reduced test case

Comment 5

[Chris Petersen]

Attachment: Sample file that contains two link for the tests

Comment 6

[Chris Petersen]

Attachment: Reduced test that fails go to the specified name section

Comment 7

[Chris Petersen]

Attachment: Slightly modified test that does work

This test is exactly the same except that it includes HR elements after the
anchor name element.

Comment 8

[rbs]

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:
http://www.mozilla.org/projects/mathml/update.html
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.

Comment 9

[rbs]

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:
http://www.w3.org/TR/MathML2/chapter2.html

But when referenced from an external file like the link I gave above, targets
are not positioned as expected.

Comment 10

[Kevin Glowacz]

MacOS X 10.1.2
Build 2002020608
I guess its been awhile, this seems to work fine for me now.

Comment 11

[Steve Dagley]

Per comments from Kevin G. and my testing of 098 marking WORKSFORME

Comment 12

[Adam Masri]

In build 2002020903, this is still happening.

- Adam

Comment 13

[Steve Dagley]

Sorry for the premature WORKSFORME - the MathML page links do work but the
developer.apple.com link for the specified test URL does not

Comment 14

[Steve Dagley]

This bug is on the list of Mac bugs identified as significant enough to merit
fixing for MachV - adding nsbeta1 keyword.

Comment 15

[Kevin McCluskey (gone)]

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.

Comment 16

[Kevin McCluskey (gone)]

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. 

Comment 17

[Steve Dagley]

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.

Comment 18

[Dave Morrison]

I see the same behavior on a page which doesn't have anything to do with images
or MacOS X.  Go to this link:

http://www.phenix.bnl.gov/software/profiles/#flat

and click on one of the links.  Wrong spot.  Put the focus in the URL bar and
hit return.  Right spot.
 

Comment 19

[Ere Maijala (slow)]

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. 

Comment 20

[praveen tummala]

Attachment: open the zip file, test.html is the starting point

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

Comment 21

[praveen tummala]

once you are able to reproduce the bug using the testcase or otherwise, clear
the cache to be able to repeat it

Comment 22

[Kevin McCluskey (gone)]

nsbeta1-

Comment 23

[Marc Dorchain]

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

Comment 24

[Boris Zbarsky [:bzbarsky]]

This is basically bug 60307

Comment 25

[Lincoln Ramsay]

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.

Comment 26

[Ere Maijala (slow)]

Attachment: A simple test case that shows the problem with some dynamic content

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.

Comment 27

[Boris Zbarsky [:bzbarsky]]

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
resizing.

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 ***