Closed Bug 373701 Opened 13 years ago Closed 11 years ago

[FIX]Connection for pushed content (e.g. WebCam) not broken if tab is out of sight but still in bfcache


(Core :: ImageLib, defect, major)

Not set





(Reporter: volkmarkostka, Assigned: bzbarsky)




(Keywords: fixed1.9.1, regression, verified1.9.0.5)


(4 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070312 Minefield/3.0a3pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070312 Minefield/3.0a3pre

Sites which uses pushed data (e.g WebCam) send an endless data stream. If you change the site in the tab the connection for the previous content is not broken/stopped. This probably related to the bfcache.
I don't know if this is intended behaviour but in this context it is at least unexpected and for people with dailup and/or volume rates it can also be an unpleasant one.

Reproducible: Always

Steps to Reproduce:
1. Visit any site
2. Visit (in the same tab) e.g. following webcam:
3. Use e.g TCPView to identify the connection
4. Use the back function to return to the previous site
5. check that the connection for the web cam is still active
Actual Results:  
Connection is still active

Expected Results:  
Connection should be stopped

Seems not to happen in FF 2
Keywords: regression
Just in case someone wants to know what the url really is:
<script>document.write('<img src="")');</script>
Hey, I'm trying to push this bug up a few levels.
Seems no-one is that concerned about it.

It does pose a problem for anyone who has security cameras
or a webcam that they monitor.

How can I mark this bug CONFIRMED?

I confirm this behaviour. It happens just like it was described in the first post.
I can confirm this behaviour on FF3b5, on Mac OS 10.4.11 and 10.5.2. Open tab to an Axis motion jpeg pushed camera. Get about 240 or so KB/s in. Open another tab to the cam...or one of the others I have...that makes no difference. Activity doubles.  Open another.  It adds another approx 240-250 KB/s in.  Close the window, one at a time or all together...the cumulative network activity caused by the connections never stops. Even with ALL tabs and/or windows closed.  Only solved by actually quiting Firefox.

This need to be marked as confirmed, I would think.
What's the autoconfirm threshold for Firefox? In some products it's as low as 2 but this bug has 7 votes and still not NEW.
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
Requesting blocking due to this being a regression.
Flags: blocking-firefox3?
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: general → general
--> Core::General

(my $0.02 is that this shouldn't block; do we have a confirmation that this is a regression?)
Flags: blocking1.9?
Well, over one year ago when the original url was still available this did not happen in FF2 as stated in the bug report. It is hard to remember the original mozillazine thread.

Two of the approx. four of five threads:
Could you help the driver out (they have A LOT on their plates to be digging through threads on forums and trying all sorts of URLs out) by confirming if this is an actual regression.  Meaning that this did not happen in Firefox 2.0.0.* but does happen in Firefox 3.0.  Also, if you have a working link, please update the URL at the top of the bug report or post it here if you do not have bugzilla 'canedit' privilages.  Thanks!
(In reply to comment #7)
> do we have a confirmation that this is a regression?
A user on mozillazine has confirmed that this is indeed a regression from Firefox 2.0.

He explicitly confirms that it does not happen with FF2.
I could not find an open webcam with that problem. Most of them where the people have problems with are private ones.

It seems to work with the open ones i could find. With all of them i can see a "Connection: close" in the sent headers.
I have this problem with
Thanks. THis one does not send a "Connection: close" header.

GET /cgi-bin/faststream.jpg?stream=full&fps=0.2&rand=425520 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008050105 Minefield/3.0pre
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: UTF-8,*
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 200 OK
Content-Type: multipart/x-mixed-replace; boundary="MOBOTIX_Fast_Serverpush"
Not gonna block final release on this.
Component: General → Networking
Flags: wanted1.9.0.x+
Flags: blocking1.9?
Flags: blocking1.9-
QA Contact: general → networking
Duplicate of this bug: 437940
Duplicate of this bug: 418847
Duplicate of this bug: 436111
Duplicate of this bug: 434439
This bug is probably a dupe of bug 338815.  That bug is older, but this bug has more activity flags and voters...
Severity: normal → major
(In reply to comment #16)
> Not gonna block final release on this.

So a new version of software introduces bugs, but thats not seen as important? Congrats, chalk up one user who will move back to FF2.
What's the point of reporting what I consider a serious bug if it's ignored?

I *cannot* use FF3 until this is resolved since mjpeg streams are a significant part of my daily work.

Shame, it's a great product otherwise - but this is a killer.

It probably doesn't affect enough people to delay the main release.

You do realize it'll probably be fixed in a point release, right? Relax. Fixes are coming.
I can understand that.  It just seemed like such an obvious and reproducible bug, that it might be fixed sooner rather than a bug that isn't reproducible, thats all.

Instead of keeping on bitching about it, how about suggesting actual ways to fix the problem.  Find some devs that know the code and CC them on this bug.  Create a patch.  Do something rather then bitch about it because the bug ha been confirmed and its a know problem.  No need for anymore "me toos" and all the other crap.
Flags: wanted1.9.1?
Duplicate of this bug: 338815
So if one hasn't the know-how to fix a bug, then one isn't allowed to report it or comment on it.  Gotcha. Check.

This is not a support forum or a debate forum.  Supposed to only post a bug, give steps to reproduce and any other pertinent information...the rest is for the forums/newsgroups.  If you are not providing technical comments or patches then you are just spamming.  Now leave this as it is, since like I said is not a place to debate.
(In reply to comment #29)
> If you are not providing technical comments or patches

One way that non-technical users who are hitting this problem could help is by finding the regression range, and you can do this by simply testing the nightly trunk builds (use a binary search to save yourself time!) to find out when exactly this got broken.

More info: <>
OK, I've just been looking through the old trunk nightly builds and I think I've found when the bug appeared.  I found the bug wasn't present in the 2006-03-11-04-trunk nightly build, but was present in the 2006-03-12-05-trunk build.  

I had a quick look at some of the checkins around that time and I think the checkins by darin<at> might have been touching the sort of code that could affect this bug:

I have no knowledge of the Firefox codebase or C++ though, so I could well be wrong.  Hopefully this'll help a developer to figure out where the problem is and get this fixed.
Blocks: 328903
Component: Networking → ImageLib
QA Contact: networking → imagelib
Flags: blocking1.9.1?
Looks like the basic issue is that imgRequestProxy::IsPending is not implemented.  It should be.  In particular, it should be pending if the underlying channel is pending.  That is, pages that have a not-fully-loaded image on them should not go into bfcache....

I'll take a shot at fixing this in a few weeks once I have a tree again, if no one else gets there first.

At least that covers the bug as filed.  The tab-closing thing I'm not sure about.  That shouldn't be putting things into bfcache.

What would help most here is if someone creates a testcase that makes it as easy as possible to tell whether the connection got restarted or not.  Ideal would be a server that for each connection pushes out a bunch of identical frames with each one containing a unique id the server assigns to that connection.  That way, the id should change on pageload and then back, right?  If someone is willing to set that up, that would save me a ton of time trying to test fixes...  If someone is willing to create a mochitest or something along those lines, that would be even more helpful.
I think I can help to provide the test environment. My tool MJPG-Streamer[1] can be used without webcams by using a special input plugin, toggling two JPEG-files and streaming them to Firefox via HTTP 1.0.

Just compile the tool from source, or grab the *.deb package if you are using Ubuntu 8.04. Then execute MJPG-Streamer as follows:

$ make clean all
$ sudo make install
$ export LD_LIBRARY_PATH="$(pwd)"
$ ./mjpg_streamer -i ""

This gives a clean and reproducible way to setup the stream source locally. I can reproduce this described bug by pointing the Firefox to

There are two annoyances:
* I have to reload the page one time, before streaming works
* The stream does not stop if I leave, the connection is not closed by Firefox as long as an instance of Firefox is still running. Leaving the page (closing tab, surfing to another URL) does not close the connection.

If you want to check if it is still buggy, or if the issue was solved you may run "wireshark" on the local loopback interface "lo". If your system is not noisy, it is already sufficient to have a look at the traffic by using a tool like "iptraf"[2] or any other bandwidth measuring tool or even a Gnome applet.

I hope this proposed test-setup helps to fix this bug.

Kind regards,

I just wanted to point out that this bug is horrendous in combination with the ZoneMinder surveillance system, since you can watch multiple MJPEG streams at once there. I ran into it after i noticed that FF3 was still pulling the images even though the corresponding windows were closed for hours(!). memory usage didn't go up, AFAIK, though.

good luck fixing this! :)
This sounds like a bfcache issue, not necessarily an imagelib one..
Component: ImageLib → Embedding: Docshell
QA Contact: imagelib → docshell
I'd like to also point out, this only occurs if the motion jpeg image is embedded in a web page as an img tag.  If the image URL is accessed directly, the stream closes when the window is closed.

Steps to reproduce this issue:

- Open a new window in FF3.
- Navigate to a web page in a new window with a motion jpeg image embedded as an img tag.
- Let the motion jpeg image stream for a-few seconds.
- Close the window.
- The motion jpeg stream is not closed.

However, instead if you:

- Open a new window in FF3.
- Navigate directly to the URL for the image, *without* it being embedded in a web page as an img tag.
- Let the motion jpeg image stream for a-few seconds.
- Close the window.
- The motion jpeg stream *will* close.

Duplicate of this bug: 445505
Just in case you need an url that still triggers the bug, does.
Open testcase in several tabs. See network load increase. Close tabs but don't close Firefox window. Network load stays.

Abort network streams by switching Firefox to offline mode.
This bug prevents all users of our gotomycamera service from using FF3. It is very unfortunate that it appeared as we are ready to launch. I confirm it was not present in FF2.

Not only the stream is not closed when the tab is closed, but on a Mac a crash will follow soon.

I can expose one or more Axis cameras for testing if needed. Unfortunately, I cannot provide assistance with fixing the bug itself. 

Please raise its priority.

Flags: blocking1.9.0.3?
A way to find public Axis network camera is to do a Google search of "inurl:/axis-cgi/mjpg/video.cgi?"

The search returns links to push streams that are good testcases.
Some background on comment 33:

Basically, imagelib coalesces loads.  So when you do a bunch of loadImage calls for the same URI, it dispatches only one network request and creates a single imgRequest for the load.  It creates one imgRequestProxy per loadImage call.

Normally, a network request would be placed in a loadgroup so that we can keep track of its status.  However, since imagelib coalesces loads across loadgroups the network request is not placed in a loadgroup.  Instead, the imgRequestProxy objects are.  These implement the nsIRequest interface, but not nsIChannel.

Now the way bfcache works is that it checks whether there are in-progress loads before deciding whether to cache the document.  This is done by calling GetRequests on the loadgroup and then seeing whether any of the requests are different from the document request for the document being loaded.

Which means that comment 33 is wrong about the IsPending() business: bfcache never checks that.  It also means that the imgRequestProxy is in fact not in the loadgroup (which honestly makes sense: the start of the new document load should have canceled any imgRequestProxies that were in the loadgroup).

So the real thing that needs to be looked into is why the imgRequestProxies are not in the relevant loadgroups.  For a multipart response, they really should be, and I thought we had code in imgRequestProxy to ensure that.  Looking at it again, though, maybe the lastPart checks are wrong.  Should be looked into.

Also the part of the patch for bug 328903 that nulls out mRequest in OnStopRequest but doesn't reinit it in OnStartRequest looks pretty fishy.  It's possible that we are in fact canceling all the imgRequestProxies and that this cancels the imgRequest but that it fails to cancel the underlying nsHttpChannel because it's no longer holding a reference to it.
So the lastPart checks are in fact correct.  I'm pretty sure that comment 43 last paragraph is where the problem is.

Note also that this is a regression of bug 308903.  We really need to add a test for this somehow.
Flags: in-testsuite?
Since the bug is not assigned to anyone yet, I would like to offer a $500 bounty for the person who provides a patch that fixes this bug. At the same time, I will donate another $500 to the Mozilla Foundation as well.
Attached file Python test server
I guess the test will depend on bug 396226. Or do you see another way?

In attachment is a small Python script for simulating a multipart image stream of images with an incrementing number on them. I'm not getting a linear image progression with Firefox 3 or 3.1, so there may be something wrong somewhere (it's fine on Firefox 2, Safari or Opera).
Yeah, there's no other way to create an automated test for this in our current frameworks.
Depends on: 396226
Duplicate of this bug: 453812
Duplicate of this bug: 453812
This looks like a dupe of bug 281480, and could it be related to bug 451457?
Duplicate of this bug: 281480
(In reply to comment #50)
> This looks like a dupe of bug 281480
That bug was opened in 2005, before the regression that caused this one. So the initial issue was probably something else. I've marked it as a duplicate of this one which contains more details.

> and could it be related to bug 451457?

I don't think so, this one is related to imagelib but the <video> element does not use it.
I looked at the diff from this checkin for a while:

and tried to follow the surrounding code.

I added a private nsIChannel (mChannel) in the imgRequest class and
changed in imgRequest::Init() and imgRequest::OnStartRequest() to save
the channel in mChannel.

At the end of OnStartRequest() there is a check if we have any
observers left with an mObservers.IsEmpty() and a call to


I added an explicit call to mChannel->Cancel() here.

Trying out my changes against an Axis camera, everything seems to work
OK and the TCP connection is now closed when I close the tab or

However, a lot of other sites breaks and shows no images what so
ever. I have no idea why, but that's probably because I don't know
ends nor tails of the Firefox code yet.

Any comments? Am I on the right track?
Post a diff?
(In reply to comment #54)
> Post a diff?

Oh. Sorry. Sure. To apply, cut and paste this text to a file called, say, "mjpeg.patch" and cd to mozilla/modules/libpr0n/src, then

% patch < mjpeg.patch

--- imgRequest.h-orig	2008-09-15 14:25:41.000000000 +0200
+++ imgRequest.h	2008-09-15 14:26:13.000000000 +0200
@@ -49,6 +49,7 @@
 #include "nsICacheEntryDescriptor.h"
 #include "nsIContentSniffer.h"
 #include "nsIRequest.h"
+#include "nsIChannel.h"
 #include "nsIProperties.h"
 #include "nsIStreamListener.h"
 #include "nsIURI.h"
@@ -151,6 +152,7 @@
+  nsCOMPtr<nsIChannel> mChannel;
   nsCOMPtr<nsIRequest> mRequest;
   nsCOMPtr<nsIURI> mURI;
   nsCOMPtr<nsIPrincipal> mPrincipal;
--- imgRequest.cpp-orig	2008-09-15 14:25:49.000000000 +0200
+++ imgRequest.cpp	2008-09-15 14:26:16.000000000 +0200
@@ -106,6 +106,7 @@
   if (!mProperties)
+  mChannel = do_QueryInterface(aRequest);
   mURI = aURI;
   mRequest = aRequest;
@@ -171,7 +172,7 @@
        This way, if a proxy is destroyed without calling cancel on it, it won't leak
        and won't leave a bad pointer in mObservers.
-    if (mRequest && mLoading && NS_FAILED(aStatus)) {
+    if (mChannel && mRequest && mLoading && NS_FAILED(aStatus)) {
       LOG_MSG(gImgLog, "imgRequest::RemoveProxy", "load in progress.  canceling");
       mImageStatus |= imgIRequest::STATUS_LOAD_PARTIAL;
@@ -292,14 +293,16 @@
-  if (mRequest && mLoading)
+ if (mChannel && mRequest && mLoading) {
+    /* Cancel both channel and request. */
+    mChannel->Cancel(aStatus);
+  }
 nsresult imgRequest::GetURI(nsIURI **aURI)
   LOG_FUNC(gImgLog, "imgRequest::GetURI");
   if (mURI) {
     *aURI = mURI;
@@ -587,7 +590,24 @@
   NS_ASSERTION(!mDecoder, "imgRequest::OnStartRequest -- we already have a decoder");
+  /* if mChannel isn't set here, use aRequest.
+   *
+   * Having mChannel set is important for Canceling the load, and
+   * since we set mChannel to null in OnStopRequest.  Since with
+   * multipart/x-mixed-replace, you can get multiple OnStartRequests,
+   * we need to reinstance mChannel so that when/if Cancel() gets
+   * called, we have a channel to cancel and we don't leave the
+   * channel open forever.
+  */
   nsCOMPtr<nsIMultiPartChannel> mpchan(do_QueryInterface(aRequest));
+  if (!mChannel) {
+    if (mpchan)
+      mpchan->GetBaseChannel(getter_AddRefs(mChannel));
+    else
+      mChannel = do_QueryInterface(aRequest);
+  }
   if (mpchan)
       mIsMultiPartChannel = PR_TRUE;
@@ -674,6 +694,8 @@
   // Shouldn't we be dead already if this gets hit?  Probably multipart/x-mixed-replace...
   if (mObservers.IsEmpty()) {
+    // Shut down the channel explictly.
+    mChannel->Cancel(NS_IMAGELIB_ERROR_FAILURE);
   return NS_OK;
@@ -711,6 +733,10 @@
     mRequest = nsnull;  // we no longer need the request
+  if (mChannel) {
+    mChannel = nsnull; // we no longer need the channel 
+  }
   // If mImage is still null, we didn't properly load the image.
   if (NS_FAILED(status) || !mImage) {
     this->Cancel(status); // sets status, stops animations, removes from cache
Next time, feel free to add the diff as an attachment at the top instead of posting the whole thing as a comment ;-)
This is totally imagelib.
Component: Document Navigation → ImageLib
QA Contact: docshell → imagelib
Attached patch FixSplinter Review
Assignee: nobody → bzbarsky
Attachment #338680 - Flags: superreview?(cbiesinger)
Attachment #338680 - Flags: review?(joe)
Summary: Connection for pushed content (e.g. WebCam) not broken if tab is out of sight but still in bfcache → [FIX]Connection for pushed content (e.g. WebCam) not broken if tab is out of sight but still in bfcache
Depends on: 455606
Bug 455606 is currently blocking me from reviewing this patch.
Attachment #338680 - Flags: review?(joe) → review+
Comment on attachment 338680 [details] [diff] [review]

Tested on 1.9.0 cvs trunk and 1.9.1 mozilla-central tip. Patch which applies to 1.9.0 upcoming.
Attachment #339356 - Flags: superreview?(cbiesinger)
Attachment #339356 - Flags: review+
I don't know if this is any help whatsoever - but we run firefox on a computer using the r-kiosk extension to run a web-based presentation of 100ish pages on a loop - now using firefox 3.0.1 the presentation connects to 6 local network cameras one after the other to show live streams - the cameras have a green led light on them which illuminate only when there is an active connection to them - making them ideal for checking the connection is closed :)

Using firefox 3.0 or 3.0.1 I can see that the connection remains open when the presentation machine navigates away from the camera page and to another page on the system. (this is witnessed by the light staying illuminated on the front of ALL cameras)

Also! Using the latest version of opera (downloaded last night) has identical results as firefox 3.0 and 3.0.1.

Using firefox 2.0.1 - the light on the cameras goes off when the page stops accessing that particular camera.

If anyone would like me to test any patches / fixes against our local cameras - I am more than happy to do this.

In case anyone wonders - we have 5x Panasonic BLC-10 Network cameras and 1x Panasonic BB-HCM331 Outdoor Network Camera.

Hope to be of assistance..

(In case anyone wants a quick source of live network cameras with which to see the problem - visit for thousands of them - this is the site where I first noticied the bug)

Andy Jones
Attachment #338680 - Flags: superreview?(cbiesinger) → superreview+
Comment on attachment 338680 [details] [diff] [review]

You can remove this comment in OnStopRequest now, right?
  // XXXldb What if this is a non-last part of a multipart request?

Or maybe replace it with a pointer to this code here.
Comment on attachment 339356 [details] [diff] [review]
Patch adapted to work on 1.9.0

+  /**

should only be /*. /** is for javadoc/doxygen

(missed that in the other patch)
Attachment #339356 - Flags: superreview?(cbiesinger) → superreview+
I was torn about that comment.  I want to leave it in pending the GetNetworkStatus thing being sorted out, since that's still wrong as things stand.  I did file another bug on that.
Pushed changeset afcc5aa0fb07.  Not sure how to unit test this yet...
Closed: 11 years ago
Resolution: --- → FIXED
Comment on attachment 339356 [details] [diff] [review]
Patch adapted to work on 1.9.0

We should take this regression fix on branch.  It should be pretty safe.
Attachment #339356 - Flags: approval1.9.0.4?
I think that bug #437917 is a duplicate of this one.
Duplicate of this bug: 437917
For the record, this was briefly backed out:
and then relanded:
during the investigation of bug 458065.
Flags: blocking1.9.0.4? → blocking1.9.0.4-
I understand that there is a patch available for this bug. But will we see this bug fixed in the upcoming Firefox 3.0.4? How can I tell for which release a patch has been applied?
Daniel, see the keywords field and the approval flags on the patch.  It hasn't been fixed on the 1.9.0.x branch yet, but the plan is to get it fixed for
Duplicate of this bug: 460261
Duplicate of this bug: 462746
Duplicate of this bug: 341959
Attachment #339356 - Flags: approval1.9.0.4? → approval1.9.0.5+
Comment on attachment 339356 [details] [diff] [review]
Patch adapted to work on 1.9.0

a=mconnor for
Fixed on 1.9 branch.
Keywords: fixed1.9.0.5
Boris, that's good news. Thanks.

I'm having problems linking those branch numbers to Firefox versions. Does "fixed on 1.9. branch" mean we will get this fix with the upcoming Firefox update, i.e. Firefox 3.0.4?
This will be fixed in Firefox 3.0.5.
Daniel, Gecko 1.9.0.x is the basis for Firefox 3.0.x (with the same 'x' in both places).  So (which is where this was fixed) will be used in Firefox 3.0.5.
Duplicate of this bug: 446381
Duplicate of this bug: 466193
Verified fixed for with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/2008120204 GranParadiso/3.0.6pre. The content no longer streams once the tab is closed. I verified the bug in 3.0.4 Firefox.

Verified fixed in trunk with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081124 Minefield/3.1b2pre.
That's great news, well done! Maybe next version I'll finally be able to upgrade to FF3.

Please note this really is not a whinge or a moan because this is free and I'm very grateful for everyone's work. This is an honest question; why has it taken over ten months to fix what on the face of it appears to be a simple bug that didn't exist before?

The problem was that, even if it seems simple, actually fixing it often isn't. It requires a sometimes unique set of knowledge that very few people possess. Boris Zbarsky, who ended up fixing this bug, is a very busy man, and there aren't a huge number of people with his set of knowledge.

In very short, Software Development Is Hard, Let's Go Shopping!

It's taken more like 21 months, as far as I can tell (the bug was first reported against 1.9a3, in March 2007).

Basically, the timeline breaks down as follows:

1) Bug reported in Firefox:General (wrong place for it, and apparently not
   triaged much, sadly).
2) It takes 11 months for someone other than the reporter to comment on the bug.
3) It takes 3 months for someone who knows how the bug system works to see the
   bug, confirm it and request blocking.
4) Almost immediately the bug is moved to Core:General (another wrong place,
   and even worse-triaged than Firefox:General).
5) The next day it's decided that the bug isn't a blocker for the release.
   It's moved into the Networking component, which is basically unowned (at the
   time, of the three peers, one (the owner) was working on Google Chrome and
   not reading bugmail, one had a non-Mozilla-related job and wasn't reading
   bugmail much, and one had a PhD defence coming up in 2 weeks time and hadn't
   been really dealing with bugmail for 6 months).
6) Nothing relevant happens for a month and a half until Adam Spain takes the
   time to go through and figure out when the bug first appeared (something
   anyone with time could have done, for what it's worth).  At this point,
   people figure out which change cased the problem and finally move the bug
   to the correct component (imagelib).  Sadly, at this point imagelib is not
   so well-owned.  The previous owner has moved on to other things, and the new
   one hasn't gotten up to speed yet. 
7) Two days later there is a guess as to how to fix the bug. Unfortunately, the
   person doing the guessing (one of the network peers mentioned above) is in
   the middle of moving from Chicago to Boston at the time and has a 7-month
   backlog of bugmail due to the the PhD thing I mentioned.
8) A month later the bug is moved out of imagelib and to docshell of all
   places, claiming that it's a bug in the bfcache, not in imagelib (this in
   spite of a regression range blaming an imagelib change).
9) Another month and a half later, there's more information about what might
   need to happen to fix this, but the commenter is still working through that
   seven-month backlog and working on bugs that are considered higher priority
   (see the "not blocking" determination earlier).
10) Another two weeks later a fix is finally attached to the bug.
11) 3 days later a patch that works for Firefox 3 is attached.
12) A week and a half later, the trunk patch gets reviewed and is checked in. 
    Approval is requested for the branch fix.
13) A month and a bit later, it's approved.  The next day it's fixed on the
14) It's another month and a half until the next branch release at this point.

I have no idea why approval took so long, but the real lag time was in getting the bug to the attention of people who had both the knowledge and the time to do something with it, combined with the lack of active code ownership in the most-relevant modules (imagelib and network).
(In reply to comment #86)
> I have no idea why approval took so long...

Branch approval took so long because we had just started a new process whereby we don't accept most patches that aren't security or stability fixes and were figuring out how to implement that properly.

(Another consequence of this is that we're approving – and thus, landing – patches much earlier in the release process than before which means it might take a while to see the fix in a released version.)
Works like a charm in Firefox 3.0.5. Thanks Boris.
(In reply to comment #88)
> Works like a charm in Firefox 3.0.5. Thanks Boris.

I am grateful to Boris and the other people who worked on this bug as well.
I think this problem still exists on Linux.

Running Firefox 3.0.5 on Ubuntu 8.04 the symptoms persist.

Open the URL below in a new tab

Now use your favourite sniffing tool (wireshark, iptraf,...) to monitor TCP traffic. Close tab. Traffic continues. Select Menu "File > Work offline". Traffic ends.
Daniel, is that an Ubuntu build or a build?  If the former, can you please test the latter?
(In reply to comment #90)

I can confirm that on current trunk, Vista. The only ways I found to end this stream is offline mode or browser quit.

-> new bug?
Boris, you are right. I am running an Ubuntu build of Firefox. I just checked the "Help > About" dialog and there you are

  Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2008071719
  Ubuntu/8.04 (hardy) Firefox/3.0.5

They call it 3.0.5 but it's from branch, not Bummer.

The problem does not exist in an build, e.g. firefox-3.0.5.tar.bz2.

So the problem is related to the Ubuntu package.
Thanks for the help and sorry for the noise.
> They call it 3.0.5 but it's from branch, not Bummer.

It means you have upgraded firefox, but not xulrunner-1.9.
Daniel, sounds like you should report a bug to Ubuntu about the fact that it allows updating Firefox without updating Gecko (leaving you with all the security holes and the perception that they're fixed).

Radek, good catch!  That's a regression from bug 89419.  I'll file that.
Bug 473161 filed on the regression.
Your are right. Checking the logs I found that I installed "firefox-3.0 3.0.5+nobinonly-0ubuntu0.8.04.1" in December. Today I ran "apt-get upgrade" and got "xulrunner-1.9" installed.

Now I am also running 

  Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2008121621
  Ubuntu/8.04 (hardy) Firefox/3.0.5
Users that don't install security updates simply don't have a secure system. If you install security updates (as suggested by system) you will get a new xulrunner too.
Flags: wanted1.9.1?
Flags: blocking1.9.1?
Flags: blocking1.9.1+
I hope you all don't mind my spamming this bug with gratitude, but I would like to thank you for fixing it. I can now use Firefox 3 to work with ZoneMinder and the fix works great; video streams stop when windows are closed as they should.
Keywords: fixed1.9.1
marking this as a regression of bug 308903 per comment 44. That's suspiciously only a one digit difference from bug 328903 mentioned previously, but the summary does sound like a plausible regressor.
Blocks: 308903
I just meant that this bug is the same as bug 308903.  As in, the checkin for bug 328903 broke the code that had been put in place to fix bug 308903.  This bug was about the resulting breakage.
No longer blocks: 308903
You need to log in before you can comment on or make changes to this bug.