The reflow after stylesheet reload messes up named anchors, moving things back up to the top of the page. See also bugs 2765 and 3152.

Troy, can you take a look at this? (or possibly hand off to whoever did scroll to named anchor on load) It needs to reset the scroll position after a frame reconstruct.

Peter, the scroll to anchor on initial load is handled by the content sink. That implementation isn't applicable here, and what needs to happen is the frame reconstruct code needs to: - detect that there's a named anchor - call nsIPresShell::GoToAnchor() passing in the anchor name It probably isn't the frame reconstruct code that should do this, because it doesn't know why the reconstruct is happening. Maybe the code that does the stylesheet reload should trigger the GoToAnchor() call?

There's the corresponding problem that a reconstruct (which can happen at any time due to a DOM call setting certain style, or turning style sheets on/off) will always reset the scrolling to the top of the window. We need a general mechanism to preserve scroll offset information accross a reconstruct (whether it be due to scroll to anchor or just the user scrolling the window). The scroll reset problem is further complicated by the fact that after the reconstruct, the content is likely to layout significantly differently. So we can't just preserve the y offset, we need to capture what element was at the top of the window and rescroll to there...

Yes, I completely agree. This is the same problem we'll have when going Back or Forward in the session history as well. Today we don't do that, either. We need to do something like: get the current element at the top of the page and then force a scroll to that element after doing the reload. How we remember the element is debatable: it's easy if it has a name, of course. Okay, I'm assigning this to Nisheeth, because he's Mr. Web Shell and the Web Shell needs to do this for Back/Forward. Then we'll just mooch off that code...

Accepting bug and setting milestone to M5...

Adding myself as cc...

Moving history and link clicking related problems to M6...

Moving non-crashing layout and webshell component bugs to M8... I already have enough blockers and crashers for M6. If I fix them in time for M6, I'll move some of these bugs back to the M6 milestone. I'm keeping the M7 milestone for fixing XML bugs.

Radha will fix this while implementing the notion of a history state object for each page. Updating summary, ccing her, and setting target milestone to M9.

Updating summary.

*** Bug 9351 has been marked as a duplicate of this bug. ***

The owner for doing the saving/reconstructing document state is still to be determined. This work will probaly happen in the M10, M11 timeframe. Moving bug out to M10 for now...

*** This bug has been marked as a duplicate of 9958 ***

Verifying bug dup of #9958 regarding the implementing the notion of a history state object