135080 - Back loads page at top on pages that use Multip-part stream converter

Status: RESOLVED DUPLICATE of bug 47350

(Core :: DOM: Navigation, defect)

Description

[john]

Some websites I go to, when I hit the back button, instead of taking me back to
same location I had scrolled down to when I selected the link, it will go back
to the very top of the previous page.  on a side note, there are sometimes when
various sites will load an image and as soon as it's done, the image will be
replaced with the image's location title.

Comment 1

[Matthias Versen [:Matti]]

What's your build ID ?
Do you have a sample URL ?

-> History:Session

Comment 2

[Radha on family leave (not reading bugmail)]

Here's some rambling I got thro' email about the bug.  These are just some
observations. I need a url and clear steps to reproduce before I can do anything
constructive on this bug ....

here is the info from my HELP:ABOUT screen: 
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+)
Gecko/20020325
i think it's my build ID.
I noticed it when I got lost on sub-pages within the
CNN website, it was under CNN sports: College
Basketball : Tourney : More news.  Click on an
article, it'd open, hit 'back' and it'd go back to the
top.  I don't have that URL.  The other one I noticed
it on, a big problem, was 
www.thehun.net
a porn listing site to free porn listings, so, if it's
not for you, don't go there looking to fix it if
you'll be offended by it.  It's a big long list so
it's important to go back to where I left off.  Also,
on some of the subsoquent image pages loaded, when you
select a picture and it opens, it'd load and then
switch to the picture ID name rather than the image
display.  This only happened on what seemed to be
certain servers but it'd be all the pictures from that
website, others would be fine.  IE doesn't have that
problem.

Comment 3

[[e-mail]]

More info:
here's an example
go to
http://bugzilla.mozilla.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=ldap&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&status_whiteboard=&status_whiteboard_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=Reuse+same+sort+as+last+time
go down one page
click on a bug id
go back
the page is now at the top rather than where you left off

Comment 4

[Radha on family leave (not reading bugmail)]

There seems to be a regression again in the scrollbar restoration code. Looking.

Comment 5

[Radha on family leave (not reading bugmail)]

cc'ing Darin and jkeiser for more info. When does nsMultiMixedConv gets sucked in?

The above url comes around for loading twice through the following stack. My
best guess is, the layhistorystate which was saved during the first time is
replaced by the second load, there by losing scrollbar positions. However, the
value returned by nsIPresShell::CaptureHistoryState() is the same in both the
loads.  I think that PresShell hands back the same handle for a single page,
eventhough internally it chnages the state info. 

nsDocShell::Embed(nsDocShell * const 0x03da4684, nsIContentViewer * 0x0514ea68,
const char * 0x02208f94, nsISupports * 0x00000000) line 3686
nsDocShell::CreateContentViewer(nsDocShell * const 0x03da4660, const char *
0x0012f9dc, nsIRequest * 0x04090f70, nsIStreamListener * * 0x0012fa2c) line 4071
+ 32 bytes
nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x03da4978,
const char * 0x0012f9dc, int 0x00000000, nsIRequest * 0x04090f70,
nsIStreamListener * * 0x0012fa2c, int * 0x0012f9c8) line 107 + 33 bytes
nsDocumentOpenInfo::DispatchContent(nsIRequest * 0x04090f70, nsISupports *
0x00000000) line 358 + 93 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x04232ec0,
nsIRequest * 0x04090f70, nsISupports * 0x00000000) line 228 + 16 bytes
nsMultiMixedConv::SendStart(nsIChannel * 0x03de3948) line 789 + 50 bytes
nsMultiMixedConv::OnDataAvailable(nsMultiMixedConv * const 0x04232f18,
nsIRequest * 0x03de3948, nsISupports * 0x00000000, nsIInputStream * 0x04216d80,
unsigned int 0x00000000, unsigned int 0x00002000) line 551 + 17 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x04086ae8,
nsIRequest * 0x03de3948, nsISupports * 0x00000000, nsIInputStream * 0x04216d80,
unsigned int 0x00000000, unsigned int 0x00002000) line 243 + 46 bytes
nsHttpChannel::OnDataAvailable(nsHttpChannel * const 0x03de394c, nsIRequest *
0x04216d78, nsISupports * 0x00000000, nsIInputStream * 0x04216d80, unsigned int
0x00000000, unsigned int 0x00002000) line 2964 + 63 bytes
nsStorageTransport::nsReadRequest::OnDataAvailable(nsStorageTransport::nsReadRequest
* const 0x04216d7c, nsIRequest * 0x04216d78, nsISupports * 0x00000000,
nsIInputStream * 0x04216d80, unsigned int 0x00000000, unsigned int 0x00002000)
line 625 + 46 bytes
XPTC_InvokeByIndex(nsISupports * 0x04216d7c, unsigned int 0x00000005, unsigned
int 0x00000005, nsXPTCVariant * 0x04194120) line 106
EventHandler(PLEvent * 0x040538a0) line 567 + 41 bytes
PL_HandleEvent(PLEvent * 0x040538a0) line 596 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x0157e658) line 526 + 9 bytes

Comment 6

[Darin Fisher]

uriloader invokes the multipart stream converter to handle a
multipart/x-mixed-replace content type.  the result as you said is multiple
OnStartRequest/OnDataAvailable/OnStopRequest sequences.

Comment 7

[Radha on family leave (not reading bugmail)]

jkeiser, I need some help from you here. I thought the scrollbar was getting
reset to the top because we capture the history state twice and set it on the
PresShell twice. And that the second call we make to
nsIPresShell->SetHistoryState() erases the restoration we do during the first
time. But that does not seem to be the case. 

I went into the debugger and manually avoided the second call we make to
CaptureHistoryState() in nsDocShell::PersistlayoutHistoryState() and
SetHistoryState() in nsDocShell::Embed(). I expected the scrollbar to be
restored to the previous position, but that did not happen. I'm not sure if
PresShell is also getting confused with the MultiMixConv. One thing I want to
point out is, when we do the second capture, the value returned by 
nsIPresShell->CaptureHistoryState() is the same as the  first one. I'm not sure
if same value usually means same state information. 

Comment 8

[John Morrison]

(isn't this bug 47350 (or vice versa)?)

Comment 9

[Radha on family leave (not reading bugmail)]

Thanks jrgm. This is a dupe of 47350. 

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