308903 - Data from streaming network cam doesn't stop when replacing the cam page with a new page.

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Bob]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050910 SeaMonkey/1.0a

Open a page that has constantly updated video (a fast 'network' cam). Replace
that page with any other page (google.com or about:mozilla or.....) Note that
the incoming video data never stops.

Reproducible: Always

Steps to Reproduce:
1. Load SM
2. Click on bookmarked url or type url of cam page. Three example urls are
   http://83.211.74.195/control/userimage.html 
   http://66.14.80.6:1600/ 
   http://151.38.151.105/ 
Cam page displays; image is continuously updated.
3. Click on bookmark of another url. I usually use about:mozilla since it uses
no network data
New url page replaces cam page. Data from earlier cam url continues to stream.
Status bar reports "Transferring data from 83.211.74.195" (or whatever) even tho
that url is no longer displayed.
4. Close SM to stop stream - the only way I have found to stop stream.


Actual Results:  
Camera data never stops.

Expected Results:  
Camera data should stop when new url is displayed.

I originally reported this at
http://forums.mozillazine.org/viewtopic.php?t=317820 . Schapel commented that
setting browser.sessionhistory.max_viewers to 0 usually fixes the problem for
him.  When set to the default 3, "The network activity  stops after I navigate
four pages away." For me, these results occasionally occur. Schapel also says
"It looks like a bfcache problem, and bug 274784 should depend on it."

Comment 1

[Ryan Flint [:rflint] (ping via IRC for reviews)]

Behavior confirmed on both FF 1.5 and SM. Disabling bfcache does indeed resolve
it. Assigning to the appropriate module and blocking bug 274784.

Comment 2

[Asa Dotzler [:asa]]

->bryner

Comment 3

[OstGote!]

other similiar issue: Bug 281480

Comment 4

[Brian Ryner (not reading)]

Attachment: patch

Comment 5

[Darin Fisher]

Comment on attachment 198080 [details] [diff] [review]
patch

It's annoying that mPartChannel is just not a nsPartChannel type, but oh well.

sr=darin

Comment 6

[Brian Ryner (not reading)]

Yeah, it's not actually that hard to make this be cleaner.  I'll post a new patch.

(In reply to comment #5)
> (From update of attachment 198080 [details] [diff] [review] [edit])
> It's annoying that mPartChannel is just not a nsPartChannel type, but oh well.
> 
> sr=darin
> 

Comment 7

[Brian Ryner (not reading)]

Attachment: patch

Comment 8

[Stuart Parmenter]

Comment on attachment 198163 [details] [diff] [review]
patch

won't this cause onload for the document to never fire on pages with these
images?

Comment 9

[Brian Ryner (not reading)]

I think it might, yeah (the testcase here loads the multipart image after
onload, so I didn't see this problem show up).

It might make more sense to remove it from the loadgroup and then re-add it with
LOAD_BACKGROUND set.

(In reply to comment #8)
> (From update of attachment 198163 [details] [diff] [review] [edit])
> won't this cause onload for the document to never fire on pages with these
> images?
> 

Comment 10

[Brian Ryner (not reading)]

Attachment: allow onload to fire

Comment 11

[Boris Zbarsky [:bzbarsky]]

"What does IE do?" as far as onload with multipart images goes?  It makes some
sense to me to not fire onload there until the image is actually done.

Comment 12

[Brian Ryner (not reading)]

IE doesn't seem to be able to handle any of the images given as testcases here.
 The sites use an alternate method for refreshing the image.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Ugh.  I guess we have to do this onload hack, then.  :(

Comment 14

[Stuart Parmenter]

Comment on attachment 198173 [details] [diff] [review]
allow onload to fire

This should be fine

Comment 15

[Darin Fisher]

Comment on attachment 198173 [details] [diff] [review]
allow onload to fire

It might be worth it to beef up the comments in imgRequestProxy.  I had to
think about it several times before I understood all the cases that needed to
be considered.

sr=darin

Comment 16

[Brian Ryner (not reading)]

checked in on the trunk.

Comment 17

[Scott MacGregor]

Comment on attachment 198173 [details] [diff] [review]
allow onload to fire

we know we have to take this even though we don't have time to let it bake so
I'm going to approve it now.

Comment 18

[Scott MacGregor]

Adding the qawanted keyword as we'll need extra testing focus on this tomorrow
morning when the builds come out. 

Comment 19

[Brian Ryner (not reading)]

checked in on the branch