Scroll position of <a name> links not being remembered in browser history.

VERIFIED FIXED

Status

()

Core
Document Navigation
VERIFIED FIXED
15 years ago
10 years ago

People

(Reporter: Jason Bassford, Assigned: Radha on family leave (not reading bugmail))

Tracking

({regression})

Trunk
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 obsolete attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030316
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030316

This is a spin-off from bug 197607.

Go to bug 197607 comment 10.  Observe that the browser has correctly scrolled so
that the 10th comment is visible.  Click back.  Click forward.  The scroll
position is now lost, and the document has been scrolled to the top.  Browser
history is ignoring the "#c10" HTML tag.

Reproducible: Always

Steps to Reproduce:
(Reporter)

Updated

15 years ago
Keywords: regression
(Reporter)

Comment 1

15 years ago
CCing Boris and David who worked on the patches for bug 197277 that might have
introduced this.
The question is, why does flushing there break framestate restoration?  jkeiser?
 Any ideas?
OS: Windows XP → All
Hardware: PC → All
bzbarsky or dbaron, who should own this bug?
Comment on attachment 117488 [details] [diff] [review]
This patch fixes it

Whoever understands how scroll state restoration works and why an innocuous
flush breaks it.  That would be you or jkeiser.

We can check in the wallpaper for now, but there seems to be a bigger
underlying issue here....

In any case, reviews for the wallpaper would be good.
Attachment #117488 - Flags: superreview?(dbaron)
Attachment #117488 - Flags: review?(radha)
Attachment #117488 - Flags: superreview?(dbaron) → superreview+
Comment on attachment 117488 [details] [diff] [review]
This patch fixes it

There's nothing particularly wrong with this wallpaper -- it's restoring what
was happening before, and there's no need to flush before changing an event
state.
Attachment #117488 - Flags: review?(radha) → review+

Comment 7

15 years ago
Yes, I concur.  It is very odd, however--I'm not clear why *not* flushing would
make save or restore ever work better.  Less flushes is always better though.
Comment on attachment 117488 [details] [diff] [review]
This patch fixes it

Checked in the patch.

jkeiser, do you want a separate bug on the issue of FlushPendingNotifications
breaking scroll state restoration here?  Or use this bug?  Or just ignore the
problem till after you finish rewriting state restoration stuff?
Attachment #117488 - Attachment is obsolete: true
(Reporter)

Comment 9

15 years ago
Confirming that the patch works in the 0318-04 Win32 build I just installed.
Regarding FlushPendingNotificaitons, I'd probably ignore it for the moment
anyway.    It might come up intermittently anyway, so I'll keep it in the back
of my head.
OK.  In that case....
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Reporter)

Comment 12

15 years ago
.
Status: RESOLVED → VERIFIED

Updated

10 years ago
Component: History: Session → Document Navigation
QA Contact: kasumi → docshell
You need to log in before you can comment on or make changes to this bug.