"multipart/x-replace-mixed" Streams do not render any but the last piece

RESOLVED INVALID

Status

()

--
major
RESOLVED INVALID
9 years ago
9 years ago

People

(Reporter: admiralnemo, Unassigned)

Tracking

3.5 Branch
x86
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Caused by Avast], URL)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 (.NET CLR 3.5.30729)

The "multipart/x-replace-method" Internet media type is supposed to be used for HTTP push communication. Each time the client receives a boundary and corresponding piece of the stream, it is supposed to clear what it has rendered already and render the next piece.

I believe this used to work in Firefox, at least I see several example pages on the web claiming it works, but it would seem to be broken in Firefox 3/3.5b4. Firefox waits for the whole stream to be downloaded, and then displays the last piece.


Reproducible: Always

Steps to Reproduce:
1. Visit the URL above
Actual Results:  
Firefox waits for the whole stream to be completely downloaded. During the download, nothing is rendered in the browser. Once it is completed, the last piece of the multipart stream is displayed

Expected Results:  
Each piece should be displayed as it is downloaded

Here's a plain-text test case
http://pyrocufflink.net/multipart-test.php

Comment 1

9 years ago
In the URL I see blinking red, blue, and green circles.  With the plain-text test case,  I see "text 0", then "text 1" and so on to "test 9".  I also see the same with Firefox 3.0.11

Please try to reproduce using Firefox 3.5 RC3 and reopen if you can reproduce with Firefox in safe mode.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 2

9 years ago
Just updated to 3.5RC, created a blank profile, and ran in safe mode. Same results as before. I am building 3.5RC on a Linux box as I type, I will reopen after testing there first.
(Reporter)

Comment 3

9 years ago
Further Test Results:

Windows 7 RC:
 * Firefox 3.0.10 - Broken as reported
 * Firefox 3.5RC - Broken as reported

Windows Vista SP2:
 * Firefox 3.0.10 - Broken as reported
 * Firefox 3.0.11 - Broken as reported

Gentoo Linux (2.6.24.3)
 * Firefox 3.1a - Works as expected

Gentoo Linux (2.6.29.3)
 * Firefox 3.5RC - Work as expected

It looks like this is a Windows related problem. I don't have Windows XP anywhere, though, so I can't test that.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---

Comment 4

9 years ago
I have Vista SP2 and this is where I confirmed that it works for me.  During one of my tries, the server seems to stop responding so maybe that is happening to you.  Only happened once out of my tries though.
(Reporter)

Comment 5

9 years ago
I started thinking about what was different about each of my test environments. In all of the Linux cases, I have nothing running but Firefox. Under Windows, there are many layers of abstraction between the actual TCP socket to the server, one of which is my Avast! anti-virus.

Disabling the "Web Shield" port 80 proxy solved the problem. Apparently, it isn't Firefox caching the stream, but Avast.

Thanks for your help. Glad I got that figured out.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → INVALID

Updated

9 years ago
Whiteboard: [Caused by Avast]

Updated

9 years ago
Version: unspecified → 3.5 Branch
You need to log in before you can comment on or make changes to this bug.