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

RESOLVED FIXED

Status

()

Core
Document Navigation
RESOLVED FIXED
12 years ago
8 years ago

People

(Reporter: Bob, Assigned: Brian Ryner (not reading))

Tracking

({fixed1.8, qawanted})

1.8 Branch
x86
Windows XP
fixed1.8, qawanted
Points:
---
Bug Flags:
blocking1.8b5 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

12 years ago
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."
Behavior confirmed on both FF 1.5 and SM. Disabling bfcache does indeed resolve
it. Assigning to the appropriate module and blocking bug 274784.
Blocks: 274784
Status: UNCONFIRMED → NEW
Component: General → History: Session
Ever confirmed: true
Product: Mozilla Application Suite → Core
Version: unspecified → 1.8 Branch
Flags: blocking1.8b5?

Comment 2

12 years ago
->bryner
Assignee: general → bryner

Comment 3

12 years ago
other similiar issue: Bug 281480

Updated

12 years ago
Flags: blocking1.8b5? → blocking1.8b5+
(Assignee)

Comment 4

12 years ago
Created attachment 198080 [details] [diff] [review]
patch
Attachment #198080 - Flags: superreview?(darin)
Attachment #198080 - Flags: review?(pavlov)

Comment 5

12 years ago
Comment on attachment 198080 [details] [diff] [review]
patch

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

sr=darin
Attachment #198080 - Flags: superreview?(darin) → superreview+

Updated

12 years ago
Whiteboard: [needs review pavlov]
(Assignee)

Comment 6

12 years ago
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
> 

(Assignee)

Updated

12 years ago
Attachment #198080 - Flags: review?(pavlov)
(Assignee)

Comment 7

12 years ago
Created attachment 198163 [details] [diff] [review]
patch
Attachment #198080 - Attachment is obsolete: true
Attachment #198163 - Flags: superreview?(darin)
Attachment #198163 - Flags: review?(pavlov)

Comment 8

12 years ago
Comment on attachment 198163 [details] [diff] [review]
patch

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

Comment 9

12 years ago
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?
> 

(Assignee)

Updated

12 years ago
Attachment #198163 - Flags: superreview?(darin)
Attachment #198163 - Flags: review?(pavlov)
(Assignee)

Comment 10

12 years ago
Created attachment 198173 [details] [diff] [review]
allow onload to fire
Attachment #198163 - Attachment is obsolete: true
Attachment #198173 - Flags: superreview?(darin)
Attachment #198173 - Flags: review?(pavlov)
"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.
(Assignee)

Comment 12

12 years ago
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.
Ugh.  I guess we have to do this onload hack, then.  :(

Comment 14

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

This should be fine
Attachment #198173 - Flags: review?(pavlov) → review+

Comment 15

12 years ago
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
Attachment #198173 - Flags: superreview?(darin) → superreview+
(Assignee)

Comment 16

12 years ago
checked in on the trunk.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Assignee)

Updated

12 years ago
Attachment #198173 - Flags: approval1.8b5?

Comment 17

12 years ago
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.
Attachment #198173 - Flags: approval1.8b5? → approval1.8b5+

Comment 18

12 years ago
Adding the qawanted keyword as we'll need extra testing focus on this tomorrow
morning when the builds come out. 
Keywords: qawanted
Whiteboard: [needs review pavlov]
(Assignee)

Comment 19

12 years ago
checked in on the branch
Keywords: fixed1.8

Updated

9 years ago
Component: History: Session → Document Navigation
QA Contact: general → docshell
Depends on: 373701
No longer depends on: 373701
You need to log in before you can comment on or make changes to this bug.