Closed Bug 70398 Opened 24 years ago Closed 23 years ago

site using multipart/x-mixed-replace content html doesn't refresh

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.3

People

(Reporter: tever, Assigned: dougt)

References

Details

Attachments

(2 files)

allowing multiple onStopRequests in URILoader
1.03 KB, patch
Details | Diff | Splinter Review
same as above without dos line endings
1009 bytes, patch
Details | Diff | Splinter Review 
Overview Description:  This site uses push technology to update a list of 
processes on a page every 10 seconds.  Only the first push causes the 
information to be displayed.  On all subsequent updates, the page is only 
partially re-drawn.

Steps to Reproduce:
1.) Go to the url listed

Actual Results:  Incomplete pages are listed every 10 seconds

Expected Results:  There should be a complete list of processes on each 
refreshed page

Build Date & Platform Bug Found:
WinNT 2001022705

Additional Builds and Platforms Tested On:
Linux 2001022714

Additional Information:
Jud may know what is causing this problem already
I'm not sure who should own this. I've verified that the multi mixed converter
is indeed parsing properly, and pushing the data out to the parser. I think the
problem lies in the parser somewhere. It looks like the data the server is
sending back doesn't contain <html></html> tags to deliniate begging and end of
a doc, so the parser doesn't know when to complete a doc.

To re-iterate, this is most likely a content problem, rather than a multi-mixed bug.
need more info. I am going to investigate this.
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9.1
Adding harish to the cc list.  He will be able to help out with parser related 
investigation.
Parser ignores HTML & /HTML from the document. In other words, parser always 
fabricates them, since they are optional tags per. spec. Parser goes with 
OnStartRequest & OnStopRequest to mark the begining and the end of a document 
respectively.
from mtg w/gagan: move target milestone to 0.9.2.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
mass move, v2.
qa to me.
QA Contact: tever → benc
Priority: -- → P3
*** Bug 69980 has been marked as a duplicate of this bug. ***
->dougt
Assignee: gagan → dougt
Gagan,  I am seeing the same thing as Jud.  The multimixed converter is pumping 
data into the parser.  We need a parser guru to look at this...  Harishd can you 
look at this?
Assignee: dougt → harishd
When does a plaintext content get processed?
a) When <PLAINTEXT> is matched by </PLAINTEXT> in the document.
b) When <PLAINTEXT> is matched by a fabricated (in the parser) </PLAINTEXT>.

Note: </PLAINTEXT> gets fabricated in the parser if the document did not contain 
</PLAINTEXT> and an OnStopRequest() is fired.

The bug here is, rather than an OnStopRequest() getting fired, a Terminate()is 
called on the parser which shuts down the parser completely without having a 
chance to fabricate </plaintext> and therefore not processing the 
plaintext content. IMO, every OnStartRequest should be matched by an 
OnStopRequest ( though I may be wrong :-/ )

Per phone coversation with dougt giving bug back to him.
Assignee: harishd → dougt
last patch allows multiple onStopRequest.

I am going to move this milestone out since the risk just went up as I had to 
touch the uriloader...
Summary: site using multipart/x-mixed-replace content doesn't refresh → site using multipart/x-mixed-replace content html doesn't refresh
The problem is that the site above is not closing their <PLAINTEXT> tag.
Target Milestone: mozilla0.9.2 → mozilla1.0
let me restate that: The problem is that we don't handle unclosed tags in 
multipart/x-mixed-replace content very well.
*** Bug 87537 has been marked as a duplicate of this bug. ***
what is milestone "mozilla1.0" anyway?  Moving to future.
Target Milestone: mozilla1.0 → Future
Doug: I think the patch would fix a bunch of related problems ( such as bug
76722, and may be bug 49539 ). Could you please reconsider the target milestone?
thanx.
I will try, but no promises.  Necko team is going to consist of just me for the 
next few weeks, so I will be swamped.
Target Milestone: Future → mozilla0.9.3
I checked in the patch into the trunk, can we verify that this has been fixed?
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
+ verifyme - I'll be testing the trunk next week.

BTW: bug 87537 was unmarked as a dupe.
Keywords: verifyme
The test case URL seems to have gone away.

Doug, where can I find a new testcase?
URL: http://www.cit.ics.saitama-u.ac.jp/cg...
ben, it should be too hard to setup an example of this.  I can remember off of
the top of my head, but maybe the 8ball doess this: http://8ball.federated.com/
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: