207897 - frame displays html source of next frame in highly nested frameset - Conn Accept -Ranconn

Status: RESOLVED EXPIRED

(Core :: Networking: HTTP, defect)

Description

[Bob Hahn]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529

In the page at concinnate.com, each frame is filled with a simple html page that
displays its name, i.e. "I am banner.php." The problem starts in frame "banner"
when the text "Conn" arrives from space after the </html> tag in banner.php. The
word "Conn" is followed by the source of the next file to be loaded,
"seminarlist.php" which is intended for the next frame in the frameset. Instead
both go into frame "banner".

The frame "seminars", which is what was supposed to get seminarlist.php, gets
filled instead with viewer.php, whose </html> tag is followed by a second
Message From Space, "Accept-RanConn". The next frame in the sequence,
"blackboard" then fills with -and displays- the source code of player.html. That
same source file (player.html) is also correctly routed to the frame "player"
where it displays as intended.

This phenomenon goes away after several refreshes, and then stays away until the
cache is cleared.

BTW, the frameset and all the pages pass CodeSweeper and all those other
validation toys in HomeSite. 

Reproducible: Always

Steps to Reproduce:
1. Clear cache
2. visit http://www.concinnate.com/frametest.html
3.

Actual Results:  
html files routed to wrong frames, one frame displays html source of following
frame.

Expected Results:  
load the files into the frames, one file per frame.

Comment 1

[Matthias Versen [:Matti]]

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

Comment 2

[Boris Zbarsky [:bzbarsky]]

Are you using HTTP pipelining?  If so, please see whether turning that off
helps, and reassign to "Networking: HTTP" (make sure to reassign to the new
component owner too) if it does.

Comment 3

[Matthias Versen [:Matti]]

>rv:1.4

Please upgrade to Mozilla 1.4RC1 or later builds. Your build is to old for
reporting bugs and this is wfm with win2k build 20030530..

Comment 4

[Boris Zbarsky [:bzbarsky]]

Matti, that build IS 1.4 rc1.  Reopening this bug.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Mail from Bob:

Yes, that made the problem go away. Curiously, it really did make it go away, as
in "I tried it the way it was, saw it fail, turned off the pipelining, cleared
the cache and saw that it worked fine, and then could not make it fail even
after turning pipelining back ON.  I'll bet the code that handles my checking
the "use pipelining" option initializes something that the 'fresh from the
factory' defaults do not.

Comment 6

[Suomi Hasler, Ayni AG]

This bug is observed also in firefox 1.0.3 on Linux 2.6.11.2.

reproducibility: ?

Comment 7

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 8

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.