Open Bug 103279 Opened 23 years ago Updated 2 years ago

Anchor scrolling happens twice, once during loading and once after page loading finishes [named anchor]

Categories

(Core :: DOM: HTML Parser, defect, P3)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
All
Type:
defect

Tracking

()

Milestone:
Future

People

(Reporter: adamlock, Unassigned)

References

(Blocks 1 open bug)

Details

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
WFM 2002 042403 on Windows 98.
Status: ASSIGNED → RESOLVED
Closed: 23 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
Blocks: 43114
Blocks: 230390
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....
Blocks: 60307
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 2.0.0.2 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.
QA Contact: moied → parser
No longer blocks: 230390
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
Assignee: dbaron → nobody
QA Whiteboard: qa-not-actionable

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --
Severity: -- → S3
You need to log in before you can comment on or make changes to this bug.