Last Comment Bug 308903 - Data from streaming network cam doesn't stop when replacing the cam page with a new page.
: Data from streaming network cam doesn't stop when replacing the cam page with...
Status: RESOLVED FIXED
: fixed1.8, qawanted
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: 1.8 Branch
: x86 Windows XP
: -- normal with 1 vote (vote)
: ---
Assigned To: Brian Ryner (not reading)
:
Mentors:
Depends on:
Blocks: blazinglyfastback
  Show dependency treegraph
 
Reported: 2005-09-16 21:00 PDT by Bob
Modified: 2009-02-14 12:46 PST (History)
13 users (show)
asa: blocking1.8b5+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (4.15 KB, patch)
2005-09-30 16:34 PDT, Brian Ryner (not reading)
darin.moz: superreview+
Details | Diff | Review
patch (8.56 KB, patch)
2005-10-01 13:35 PDT, Brian Ryner (not reading)
no flags Details | Diff | Review
allow onload to fire (10.61 KB, patch)
2005-10-01 16:34 PDT, Brian Ryner (not reading)
pavlov: review+
darin.moz: superreview+
mscott: approval1.8b5+
Details | Diff | Review

Description Bob 2005-09-16 21:00:56 PDT
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) 2005-09-16 21:39:37 PDT
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] 2005-09-22 10:56:01 PDT
->bryner
Comment 3 OstGote! 2005-09-22 16:50:30 PDT
other similiar issue: Bug 281480
Comment 4 Brian Ryner (not reading) 2005-09-30 16:34:56 PDT
Created attachment 198080 [details] [diff] [review]
patch
Comment 5 Darin Fisher 2005-09-30 16:56:43 PDT
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) 2005-10-01 13:34:53 PDT
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) 2005-10-01 13:35:53 PDT
Created attachment 198163 [details] [diff] [review]
patch
Comment 8 Stuart Parmenter 2005-10-01 14:36:23 PDT
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) 2005-10-01 14:57:10 PDT
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) 2005-10-01 16:34:40 PDT
Created attachment 198173 [details] [diff] [review]
allow onload to fire
Comment 11 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-10-02 08:53:15 PDT
"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) 2005-10-02 12:46:21 PDT
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 [:bz] (Out June 25-July 6) 2005-10-02 13:05:51 PDT
Ugh.  I guess we have to do this onload hack, then.  :(
Comment 14 Stuart Parmenter 2005-10-03 12:36:18 PDT
Comment on attachment 198173 [details] [diff] [review]
allow onload to fire

This should be fine
Comment 15 Darin Fisher 2005-10-03 14:57:29 PDT
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) 2005-10-03 15:27:49 PDT
checked in on the trunk.
Comment 17 Scott MacGregor 2005-10-03 15:39:18 PDT
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 2005-10-03 15:39:58 PDT
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) 2005-10-03 16:27:24 PDT
checked in on the branch

Note You need to log in before you can comment on or make changes to this bug.