307406 - Parser interrupted while data is still being transfered will not be resumed without more data arriving

Status: RESOLVED INCOMPLETE

(Core :: DOM: HTML Parser, defect, P5)

Description

[Giuliano Gagliardi]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050815 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050815 Firefox/1.0.6

When the HTML Parser is interrupted, while the whole page hasn't been transfered
yet, it won't resume before more data arrives. This is a problem for pages that
rely on "html streaming"/"incremental rendering", because the incomplete page
will not always be rendered up to the point it has been transfered, but only up
to the parser interruption.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Blake Kaplan (:mrbkap) (inactive)]

I think we can always post a parser continue event when we're interrupted, and
then it becomes a race between more data arriving or us hitting our parser
continue event. Are there any pitfalls I might be missing?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Is it ok if we run out of data while a continue parsing event is up?

If so, sounds like this should Just Work.

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

I'm not sure how that would happen. My plan was to revoke the parser continue
event if there was an OnDataAvailable call before we received the new event. We
could also just ignore a parser continue event once we've hit EOF (this should
be fairly easy to detect).

Comment 4

[Boris Zbarsky [:bzbarsky]]

Yeah, either way sounds reasonable.

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: wip

This needs some more cleanup before it's ready for reviews. I'm not really sure how to test that this patch won't be doing bad things, but it seems to work.

Is there a testcase I can use to make sure it's doing the right thing wrt loading all content, even if the parser gets interrupted in the middle of a chunk?

Comment 6

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.

Comment 7

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.