275890 - [FIXr]When one of frames in frameset has no content (http 204), back button doesn't work, no history entry added

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect, P1)

Description

[Jungshik Shin]

At the site given in the url, history doesn't work at all and back button
doesn't work. 

Both suite 1.7.x/ff 1.0 and trunk builds have the same problem.  This may be a
dupe. I'll check that out later after coming up with a reduced test case.

Comment 1

[Jungshik Shin]

Pages at the above site has two frames, top.asp and 'unian1.asp' :

<frameset rows="0, 1*" border="0">
    <frame src="top.asp" noresize scrolling="no" marginwidth="0" marginheight="0">
    <frame src="unian1.asp" scrolling="auto" marginwidth="0" marginheight="0">
    <noframes>
    ....
   </noframes>
</framset> 

However, top.asp has no content. IIS returns the following response:

 1 HTTP/1.1 204 No Content
 2 Server: Microsoft-IIS/5.0
 3 Date: Fri, 24 Dec 2004 09:40:21 GMT
 4 Connection: keep-alive
 5 Connection: Keep-Alive
 6 Content-Length: 59
 7 Content-Type: text/html
 8 Cache-control: private

HTTP 1.1 (RFC 2616) 10.2.5 has the following about '204 No Content'. 

   If the client is a user agent, it SHOULD NOT change its document view
   from that which caused the request to be sent. This response is
   primarily intended to allow input for actions to take place without
   causing a change to the user agent's active document view, although
   any new or updated metainformation SHOULD be applied to the document
   currently in the user agent's active view.

Comment 2

[Jungshik Shin]

darin, does this also belong to docshell as bug 183407 does? 

Comment 3

[Boris Zbarsky [:bzbarsky]]

The only thing that comes to mind is that docshell starts the load, then URILoader drops it 
on the floor due to the 204 response, but docshell still thinks the load is in progress 
somehow... except that docshells deal with retargeted loads, don't they?  That is, loads 
that start in a docshell, then get bounced to another docshell because a parent uri 
content listener rejects the load?

In any case, I'm betting the problem is that there's mismatch somewhere between the 
progress listener notifications docshell expects and the ones it gets....  Given that we're 
ending up in OnStartRequest, could it be that we're actually doing the progress start 
notifications on the docshell too?  Those are triggered by the OnStartRequest of the 
loadgroup, aren't they?

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase that doesn't need 204 response

Just load this testcase in a new browser window.  Follow directions in the
topmost visible frame.

Comment 5

[Boris Zbarsky [:bzbarsky]]

OK, biesi was right.  This is a pure session history issue...

The problem here is that entries are added to session history in OnNewURI.  If
OnNewURI doesn't get called, a session history entry will not be added at that
spot in the list (docshells know their number in their parent, and insert the
session history entries in the corresponding place in the list).

Now when we do a subframe navigation, we end up in the
nsDocShell::CloneAndReplace method, where we walk the entire session history
tree and clone it all, changing the one history entry corresponding to the
subframe that we navigated in.

In that method, we bail out with an error if we hit a null child of an entry in
the history tree.  So the session history never gets updated in this case.  I
think the right thing to do is to simply skip over the null entries and
propagate them as null to the cloned tree.  I'll attach a patch to that effect
in a second; it fixes the testcase and the original URL this bug is reported on.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix

Comment 7

[Boris Zbarsky [:bzbarsky]]

Fixed for 1.8b