Open Bug 103279 Opened 19 years ago Updated 2 years ago
Anchor scrolling happens twice, once during loading and once after page loading finishes [named anchor]
The current fix to make anchor scrolling more immediate (see bug 58661) scrolls to the anchor twice - once during the HTML content sink's timer routine and once again after page loading completes. We sometimes need the second scroll but it should be stopped from happening if the user has already scrolled the page after the scrolling to the anchor the first time. Perhaps we should only perform the second scroll op if the vertical scrollbar position in the document does not change in between? Note that the reason for second scroll operation is to correct for any further changes to the named elements position during layout, e.g. if it's surrounded by slow-loading graphics that move it around. So the second scroll op has a real purpose.
The scroll position should not be affected in a large way by image elements loading. The fact that it does is bug 60307. The onload scroll should just be removed. It does not look good that Mozilla - undoes the user's manual scrolling. - jumps to a named anchor, moves around randomly a few times, and then jumps back to correct for that.
Severity: normal → major
Summary: Anchor scrolling happens twice, once during loading and once after page loading finishes → Anchor scrolling happens twice, once during loading and once after page loading finishes [named anchor]
The purpose for the second scroll is in case the named element is underneath something that could shift it off the screen. For example: <img src="somehumungousimage.jpg"> <p name="blah">Some anchor text</p> In this instance, the place we initially scroll to would be incorrect because the named element would be pushed down when the image begins loading.
This is Kevin's area.
Assignee: harishd → kmcclusk
Adam, your example shouldn't cause the paragraph to be pushed off the screen when the page loads. If it does, that's bug 60307.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
Bulk moving Mozilla1.01 bugs to future-P1. I will pull from the future-P1 list to schedule bugs for post Mozilla1.0 milestones
Priority: -- → P1
Target Milestone: mozilla1.0.1 → Future
WFM 2002 042403 on Windows 98.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
No, this is still done. To reproduce: 1. Load an url, containging an anchor, to a long page that is *not* in your cache. For example http://www.w3.org/TR/DOM-Level-2-Core/core.html#DOMString 2. Immideatly after mozilla scrolls to the anchor scroll down using page-dn a few times 3. Wait until the page finishes to load Once the page is done loading mozilla will scroll back to the anchor. You might need to be quite quick in step 2.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I think the following approach should be taken for fixing this bug: We should unify these two scrolling mechanisms and the scrolling mechanism for session history state restoration into one mechanism (perhaps in the pres shell, which manages reflows and also should know about coordinates?). The second scroll (or is it the first?) has the nasty habit of overriding the saved session history state, which it shouldn't (try loading http://www.w3.org/TR/REC-CSS1#important , scrolling down a few pages, and reloading). When the page begins loading, we should determine the type of positioning target: either session history, anchor, or none. After *each* reflow during page load we should scroll to the target if: (the target positioning type (see above) is not none) and (we haven't yet scrolled to the target in a way that placed the target at the top of the page) and (the user hasn't yet scrolled) or ((we haven't yet scrolled to the target at all) and (the target positioning type is anchor (or should we do this for session history as well?))) This will correct: * the problem that the second jump doesn't occur until the page finishes loading, when it usually could occur in the next batch of data (which is annoying for long documents) * the problem that the second jump occurs after the user has scrolled to another location (is this also an issue for the first jump?) * the conflict between session history and anchors mentioned above Any thoughts on this proposal? I'm a bit unsure about the issue of first-jump versus user-scroll, particularly with session history restoration.
All in all i think your proposal sounds very good (especially the part about scrolling to anchor after each reflow) Though I don't quite understand your logic-expression for when scrolling should be done, you indentation and parenthesis doesn't match towards the end. > * the problem that the second jump occurs after the user has scrolled to > another location (is this also an issue for the first jump?) I would say this is impossible to always do right. When we load an url with an anchor and the user starts scrolling before we do the first scroll she/he is either a) looking for the requested info (which is at the anchor) or b) reading/looking at something else on the page My guess is that a) is more common, which would mean that we should always scroll to the anchor when it is first loaded. One thing that might be a good idea is to wait with showing the new page until the anchor has been loaded. That would compleatly eliminate the first jump (and in many cases there is no second jump), however it could also give the impression of unresponsiveness and longer loadtimes.
I think Mozilla should only scroll to the target when it first becomes possible to position the target at the top of the viewport. It would be annoying if Mozilla scrolled multiple times as the text below the anchor continued to load.
*** Bug 219307 has been marked as a duplicate of this bug. ***
Taking bug, since I'd like to work on it, although I'm probably not going to have time in the near future.
Assignee: kmcclusk → dbaron
Status: REOPENED → NEW
The bug still exists. Loading a page with pictures and anchor behind pictures shows the anchor place, but after images are loaded the page stays in wrong place. Example URL: http://www.mb.org.pl/forum/showflat.php?Cat=&Board=pm&Number=45762#Post45763
You're talking about bug 60307, not _this_ bug. And why would this bug not still exist? It's still open....
Keep in mind that all scrollframes restore session history state, not just the root scrollframe on a document. Hmm, what should happen if say, the anchor is contained in an overflow:auto DIV? Should we scroll both the root and the DIV to bring it into view? What if the DIV's history state says it needs to be scrolled to a certain position? Then what if that position becomes available before the anchor is detected in the DIV? We can't avoid double-scrolling the DIV by choosing the scroll type ahead of time, since we don't know if the anchor will be found in the DIV or not. So how about this approach: We record in the prescontext a flag to indicate whether we expect to scroll to an anchor. It's set when we start loading a URI with an anchor, and it's cleared when we start loading a URI without an anchor, or when the anchor content is initially reflowed, or when page load completes. After a reflow during page load if the flag is unset, and once after page load completes, we scan all scrollframes and ask them all to scroll; the target positioning type is the anchor, if the anchor is somewhere inside the scrollframe, or else to the session history position, if any. Each scrollframe records a) whether it has scrolled to the target at all, and b) whether it has successfully scrolled the target to the top. Then each scrollframe can make this decision: We should scroll to the target if: (the target positioning type is not none) and (we haven't yet scrolled to the target in a way that placed the target at the top) and (the user hasn't yet scrolled) or ((we haven't yet scrolled to the target at all) and (the target positioning type is anchor (or should we do this for session history as well? --- I think not))) The scan of the scrollframes can be reasonably efficient by walking the view tree looking for nsScrollingViews and then finding the associated frames. This only thing this doesn't do, which we could do, is allow a scrollframe to scroll to its session history position once its element has closed and we know the anchor was not found in there. I don't think this matters much and it could be quite expensive to fix because we don't propagate "element closed" notifications out of the content sink for performance reasons. One thing that I'd really like is if we actually selected the anchor. Also, I'm soon going to move the session history code out of nsScrollBoxFrame, up to nsHTML/XULScrollFrame (hopefully shared in nsGfxScrollFrameInner).
Uhm, I'm not sure if I'm missunderstanding you, but I think it's much simpler then that. When going "back" we should never scroll to the named anchor, we should just restore the saved states of all scrollframes from the sessionhistory. I'm pretty sure that's how we already behave. When a user (or at least I) go "back" (s)he always expects to see a pages as similar as possible to the one (s)he left. It doesn't matter what the page looked like when it was opened, only what it looked like when it was left. So this bug is only about chaning the bahaviour when the user follows a link to a page. You are right that we need to consider the case when the target anchor lives in a scrolled view. In that case I think that we should recursivly scroll all views to make the anchor visible.
Okay. Then we need to determine at the beginning of a load whether we're going to try to scroll to an anchor. If we are, then we need to set a flag on the prescontext so that scrollframes do not try to scroll themselves based on session history.
The answer is extremely simple -- if we have session history state to restore, then we don't scroll to an anchor. I don't see what the fuss is about, and whatever it is, I don't think it belongs on this bug.
(In reply to comment #2) > The purpose for the second scroll is in case the named element is underneath > something that could shift it off the screen. > > For example: > > <img src="somehumungousimage.jpg"> > <p name="blah">Some anchor text</p> > In this instance, the place we initially scroll to would be incorrect because > the named element would be pushed down when the image begins loading. This is strange that since 2001-10-06 the bug still exists. I can confirm that, using firefox 18.104.22.168 on MacOSX, pages doesn't position correctly on anchors when images are preceeding the anchor. Clicking on the 'refresh' button will make it: as the images have already been loaded, page will scroll to the correct position. But if you click shift-refresh or if this is the first time you come to the page, you'll be scrolled at a wrong position. Will there be any fixes for that ? (we still can preload images on some important pages of course, but fixing this would be better)
This error hasn't been fixed for a 6 years! Why?? :'-((
(In reply to comment #13) > Taking bug, since I'd like to work on it, although I'm probably not going to > have time in the near future. Hey!! You are working on this bug for a 3 years yet! Please, wake up!!
(In reply to comment #23) > (In reply to comment #13) > > Taking bug, since I'd like to work on it, although I'm probably not going to > > have time in the near future. > > Hey!! You are working on this bug for a 3 years yet! Please, wake up!! > If your so concerned why don't you fix it? Unless your going to post something that will help then your really not helping and that's going against The Bugzilla Etiquette: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
(In reply to comment #24) > If your so concerned why don't you fix it? But how I can fix it?
(In reply to comment #25) > But how I can fix it? > The same way everyone else learns to fix things. If you don't want to put the time / effort into it then you'll just have to be patient and wait for someone else to fix it.
Moving to p3 because no activity for at least 24 weeks. See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.