1. Open a new browser window pointing to any web site. 2. Copy this URL and paste it into the browser's location field: http://twain.mcom.com/client/infodsgn/cck-emojo/CCKDocs/advanced_cck.htm#14363 What happens: The browser scrolls to the correct target ("Important Legal Restrictions") momentarily, then scrolls down to a point a few incheds below the target. Clicking in the location field and hitting return brings the correct target back into view.
Urgh, I hate it when people report bugs with mcom addresses. Reporter: Could you please attach the page in question to this bug report, or produce a simple testcase without any NS-specific data, or finally say that emojo will be out in a couple of days and point to the doc on an external server :-) Thanks
I haven't yet been able to reproduce this problem on a publicly available web page. It may be an artifact of the particular HTML in the attached page (from a document in progress). To see the problem, put this page somewhere on your hard disk and use a file:/// URL to open this target: advanced_cck.htm#14329. The browser will scroll a bit too far. To see the actual target, put click in the location field and hit return. The page then scrolls up a few inches to the correct target.
see bug 80141 I can confirm this bug. I can't find a copy of it for Windows, so this will be it I guess. Hopefully this bug doesn't get security restrictions applied because of the NS-Only info. Moving to Layout and changing summary to "anchor" which is the better word. This quite possibly is OS all, and so then 80141 should be marked as such and this should be a dup. It appears that we scroll to the right position as soon as the anchor is available to us, but when we reflow due to pictures etc we don't follow the anchor where it goes.
I cannot get this to happen with otehr pages, I tried a few from mozilla.org (http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsLineLayout.cpp#1698 for example). I'm not sure how this is a layout issue, nor am I sure who is doing scroll-to-anchor work these days. Please feel free to reassign if you are more informed than I am. Shelving for now sicne this appears isolated.
Did you try a page with lots of graphics? That seems to be a requirement to reproduce this bug. I was able to reproduce it with this URL: http://docs.iplanet.com/docs/manuals/cms/42sp2/setup_guide/cmsintro.htm#37363. It doesn't happen consistently, but it did happen the first time. This is potentially serious for any documents that include lots of graphics. Basically links start looking like they don't work, because they don't take you where they're supposed to. However, you're right that it does appear to be limited, at any rate it doesn't always happen. Only with documents that I write, perhaps . . .
Sean, your comment about images made me think of something that happens with image loading. If an image comes before an anchor, and we scroll to the anchor while the image is not fully loaded, then the anchor will be in a different spot then when the image completes loading. For example, a page like: ------------------------| || | | || | | || | |----------------------| <A NAME="foo">Anchor Point</A> will actually look like this before the image is loaded: <A NAME="foo">Anchor Point</A> so the offset into the document for the anchor will be different before and after the image loads. Thus, if the image is loaded really really fast (like, from cache), then the offset will be correct, but if it loads slowly, then it will be wrong. This is all just a big fat guess. Note however, that if you turn image loading OFF, it scrolls to the correct spot always (I think).
*** This bug has been marked as a duplicate of 89552 ***