Closed Bug 80141 Opened 19 years ago Closed 17 years ago
Anchor moves to wrong position
4.70 KB, application/zip
1.38 KB, text/html
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
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.
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
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: 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.
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: 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.
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
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
In build 2002020903, this is still happening. - Adam
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Sorry for the premature WORKSFORME - the MathML page links do work but the developer.apple.com 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.
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.
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: 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.
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.
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
once you are able to reproduce the bug using the testcase or otherwise, clear the cache to be able to repeat it
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
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.
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 ***
Status: REOPENED → RESOLVED
Closed: 18 years ago → 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.