Firefox does not close TCP connections for "multipart/x-mixed-replace" (e.g. motion JPEG) when closing page.

[Gerard Lommerse]

Binary package hint: firefox-3.0

Firefox 3.0b5 (Ubuntu Hardy):

1) Ubuntu 8.04 (release 8.04)
2)
firefox:
  Installed: 3.0~b5+nobinonly-0ubuntu3
  Candidate: 3.0~b5+nobinonly-0ubuntu3
  Version table:
 *** 3.0~b5+nobinonly-0ubuntu3 0
        500 http://nl.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

ubufox:
  Installed: 0.5-0ubuntu1
  Candidate: 0.5-0ubuntu1
  Version table:
 *** 0.5-0ubuntu1 0
        500 http://nl.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

3) I expect that the TCP connection (for streaming "multipart/x-mixed-replace" content) is closed when navigating away from the page (go to another URL or close the TAB page)

4) The TCP connection is not closed when navigating away from page (and thus consumes unnecessary amount of bandwidth)

When closing pages with "multipart/x-mixed-replace" content (e.g. motion JPEG used for AXIS network cameras), by either navigating away or closing the corresponding TAB page the TCP connection is not closed (remains 'ESTABLISHED') and server providing data (motion JPEG) keeps pushing data (and firefox keeps accepting). This consumes an unnecessary amount of bandwidth. Workaround is to close firefox altogether in order to close TCP connections.

Fragment:

GET /axis-cgi/mjpg/video.cgi?camera=&resolution=352x240&1209661363365 HTTP/1.1

Host: itwebcam.mesastate.edu

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008041514 Firefox 2.0.11

Accept: image/png,image/*;q=0.8,*/*;q=0.5

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: http://itwebcam.mesastate.edu/view/view.shtml

HTTP/1.0 200 OK

Connection: Close

Server: Camd

Content-Type: multipart/x-mixed-replace; boundary=--myboundary

--myboundary

Content-Type: image/jpeg

...

ProblemType: Bug
Architecture: i386
Date: Thu May 1 21:02:25 2008
DistroRelease: Ubuntu 8.04
NonfreeKernelModules: nvidia
Package: firefox-3.0 3.0~b5+nobinonly-0ubuntu3
PackageArchitecture: i386
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.24-16-generic i686

[Volkmarkostka (volkmarkostka)]

Just in case someone wants to know what the url really is:
<script>document.write('<img src="http://200.33.20.6/axis-cgi/mjpg/video.cgi?resolution=320x240&dummy=garb")');</script>

[N1gp (n1gp)]

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?

Thanks

[Yan-mosyagin (yan-mosyagin)]

I confirm this behaviour. It happens just like it was described in the first post.

[Matt Nelson (mattknows)]

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.

[Victor Bielawski (bielawski1)]

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.

[Supernova00 (supernova00)]

Requesting blocking due to this being a regression.

[Gerard Lommerse (gerard-lommerse)]

Binary package hint: firefox-3.0

Firefox 3.0b5 (Ubuntu Hardy):

1) Ubuntu 8.04 (release 8.04)
2)
firefox:
  Installed: 3.0~b5+nobinonly-0ubuntu3
  Candidate: 3.0~b5+nobinonly-0ubuntu3
  Version table:
 *** 3.0~b5+nobinonly-0ubuntu3 0
        500 http://nl.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

ubufox:
  Installed: 0.5-0ubuntu1
  Candidate: 0.5-0ubuntu1
  Version table:
 *** 0.5-0ubuntu1 0
        500 http://nl.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

3) I expect that the TCP connection (for streaming "multipart/x-mixed-replace" content) is closed when navigating away from the page (go to another URL or close the TAB page)

4) The TCP connection is not closed when navigating away from page (and thus consumes unnecessary amount of bandwidth)

When closing pages with "multipart/x-mixed-replace" content (e.g. motion JPEG used for AXIS network cameras), by either navigating away or closing the corresponding TAB page the TCP connection is not closed (remains 'ESTABLISHED') and server providing data (motion JPEG) keeps pushing data (and firefox keeps accepting). This consumes an unnecessary amount of bandwidth. Workaround is to close firefox altogether in order to close TCP connections.

Fragment:

GET /axis-cgi/mjpg/video.cgi?camera=&resolution=352x240&1209661363365 HTTP/1.1

Host: itwebcam.mesastate.edu

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008041514 Firefox 2.0.11

Accept: image/png,image/*;q=0.8,*/*;q=0.5

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: http://itwebcam.mesastate.edu/view/view.shtml

HTTP/1.0 200 OK

Connection: Close

Server: Camd

Content-Type: multipart/x-mixed-replace; boundary=--myboundary

--myboundary

Content-Type: image/jpeg

...

ProblemType: Bug
Architecture: i386
Date: Thu May 1 21:02:25 2008
DistroRelease: Ubuntu 8.04
NonfreeKernelModules: nvidia
Package: firefox-3.0 3.0~b5+nobinonly-0ubuntu3
PackageArchitecture: i386
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.24-16-generic i686

[Beltzner (beltzner)]

--> Core::General

(my $0.02 is that this shouldn't block; do we have a confirmation that this is a regression?)

[Volkmarkostka (volkmarkostka)]

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:
http://forums.mozillazine.org/viewtopic.php?t=646823
http://forums.mozillazine.org/viewtopic.php?t=652705

[Volkmarkostka (volkmarkostka)]

Found the original thread:
http://forums.mozillazine.org/viewtopic.php?t=528086

Please note these posts:
http://forums.mozillazine.org/viewtopic.php?p=2788171#2788171
http://forums.mozillazine.org/viewtopic.php?p=2791985#2791985

[Supernova00 (supernova00)]

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!

[Supernova00 (supernova00)]

(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.

[Volkmarkostka (volkmarkostka)]

http://forums.mozillazine.org/viewtopic.php?p=3358066#3358066

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.

[Yan-mosyagin (yan-mosyagin)]

(In reply to comment #12)

Try this search query: http://www.google.com/search?&q=inurl%3AindexFrame.shtml+Axis

[Jsl-vol (jsl-vol)]

I have this problem with http://karren.protask.at

[Volkmarkostka (volkmarkostka)]

Thanks. THis one does not send a "Connection: close" header.

http://karren.protask.at/cgi-bin/faststream.jpg?stream=full&fps=0.2&rand=425520

GET /cgi-bin/faststream.jpg?stream=full&fps=0.2&rand=425520 HTTP/1.1
Host: karren.protask.at
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
Referer: http://karren.protask.at/cgi-bin/guestimage.html

HTTP/1.x 200 OK
Content-Type: multipart/x-mixed-replace; boundary="MOBOTIX_Fast_Serverpush"

[Beltzner (beltzner)]

Not gonna block final release on this.

[Kliu (kliu)]

*** Bug 437940 has been marked as a duplicate of this bug. ***

[Kliu (kliu)]

*** Bug 418847 has been marked as a duplicate of this bug. ***

[Kliu (kliu)]

*** Bug 436111 has been marked as a duplicate of this bug. ***

[Kliu (kliu)]

*** Bug 434439 has been marked as a duplicate of this bug. ***

[Kliu (kliu)]

This bug is probably a dupe of bug 338815. That bug is older, but this bug has more activity flags and voters...

[Matt Nelson (mattknows)]

(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.

[Digdilem (digdilem)]

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.

[Zorin (zorin)]

Simon,

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.

[Matt Nelson (mattknows)]

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.

Thanks.

[Supernova00 (supernova00)]

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.

[Kliu (kliu)]

*** Bug 338815 has been marked as a duplicate of this bug. ***

[Matt Nelson (mattknows)]

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.

[Supernova00 (supernova00)]

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.

[Kliu (kliu)]

(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: <http://wiki.mozilla.org/QA#What_We_Use>

[Adamspain+mozilla-bugs (adamspain+mozilla-bugs)]

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>meer.net might have been touching the sort of code that could affect this bug:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-03-11+00%3A00%3A00&maxdate=2006-03-12+00%3A00%3A00&cvsroot=%2Fcvsroot

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.

[Steve-england (steve-england)]

Better range from comment 31 (good job Adam)

Checkins to module PhoenixTinderbox between 2006-03-11 03:00 and 2006-03-12 06:00 :

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-03-11+03&maxdate=2006-03-12+06&cvsroot=%2Fcvsroot

[Bzbarsky (bzbarsky)]

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.

[Tom-stoeveken (tom-stoeveken)]

Hi,
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 "input_testpicture.so"

This gives a clean and reproducible way to setup the stream source locally. I can reproduce this described bug by pointing the Firefox to http://127.0.0.1:8080/?action=stream

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,
Tom

[1] http://mjpg-streamer.sourceforge.net/
[2] http://iptraf.seul.org/

[schweini (schweini)]

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! :)

[Vladimir Vukicevic (vvuk)]

This sounds like a bfcache issue, not necessarily an imagelib one..

[Jkbrowne (jkbrowne)]

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.

[Matti-mversen (matti-mversen)]

*** Bug 445505 has been marked as a duplicate of this bug. ***

[Bzbarsky (bzbarsky)]

Comment on attachment 339356
Patch adapted to work on 1.9.0

We should take this regression fix on branch. It should be pretty safe.

[Stuart Hickinbottom (stuart-hickinbottom)]

I can confirm this in Firefox 3.0.3 in Hardy. I see this problem using the ZoneMinder webcam application.

I believe it may be this Mozilla bug, which has recently been fixed:
https://bugzilla.mozilla.org/show_bug.cgi?id=373701

[Johnathon (kirrus)]

Moving the remote watch to Suart's catch. Nice one :)
So, now all we have to do is wait for that patch to hit upstream's trunk, and filter down. We could patch Ubuntu's firefox for it, but there's probably not much point. What do you think?

[Johnathon (kirrus)]

Assigned this to the wrong team.. I'm more rusty at triage than I thought... :/

[Johnathon (kirrus)]

I think that bug #437917 is a duplicate of this one.

[Bzbarsky (bzbarsky)]

*** Bug 437917 has been marked as a duplicate of this bug. ***

[Stuart Hickinbottom (stuart-hickinbottom)]

I have difficulty deciphering what releases Mozilla fixes go into, but if this means it'll end up in a point release at some point in the 3.0 cycle then that's fine with me. Thanks very much.

[L. David Baron (dbaron)]

For the record, this was briefly backed out:
http://hg.mozilla.org/mozilla-central/rev/d07aa0d0712a
and then relanded:
http://hg.mozilla.org/mozilla-central/rev/f9dccfb26ec9
during the investigation of bug 458065.

[Bugzilla-kabsi (bugzilla-kabsi)]

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?

[Bzbarsky (bzbarsky)]

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 1.9.0.4.

[Matti-mversen (matti-mversen)]

*** Bug 460261 has been marked as a duplicate of this bug. ***

[Matti-mversen (matti-mversen)]

*** Bug 462746 has been marked as a duplicate of this bug. ***

[Bzbarsky (bzbarsky)]

*** Bug 341959 has been marked as a duplicate of this bug. ***

[Mike Connor (mconnor)]

Comment on attachment 339356
Patch adapted to work on 1.9.0

a=mconnor for 1.9.0.5

[Bzbarsky (bzbarsky)]

Fixed on 1.9 branch.

[Bugzilla-kabsi (bugzilla-kabsi)]

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?

[Samuel-sidler+old (samuel-sidler+old)]

This will be fixed in Firefox 3.0.5.

[Bzbarsky (bzbarsky)]

Daniel, Gecko 1.9.0.x is the basis for Firefox 3.0.x (with the same 'x' in both places). So 1.9.0.5 (which is where this was fixed) will be used in Firefox 3.0.5.

[Matti-mversen (matti-mversen)]

*** Bug 446381 has been marked as a duplicate of this bug. ***

[Matti-mversen (matti-mversen)]

*** Bug 466193 has been marked as a duplicate of this bug. ***

[Scott Garman (sgarman)]

Yes, see comment #79 on the mozilla bug report. Looks like the fix will be rolled into Firefox 3.0.5. I'm looking forward to it too.

[Abillings (abillings)]

Verified fixed for 1.9.0.5 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.6pre) 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.

[Digdilem (digdilem)]

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?

[Joe-drew (joe-drew)]

Simon,

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!

Joe

[Bzbarsky (bzbarsky)]

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
    branch.
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).

[Samuel-sidler+old (samuel-sidler+old)]

(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.)

[Bugzilla-kabsi (bugzilla-kabsi)]

Works like a charm in Firefox 3.0.5. Thanks Boris.

[Marcoeg (marcoeg)]

(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.

[Bugzilla-kabsi (bugzilla-kabsi)]

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

  http://www.videovalvonta.fi/control/faststream.jpg?html&stream=full

Now use your favourite sniffing tool (wireshark, iptraf,...) to monitor TCP traffic. Close tab. Traffic continues. Select Menu "File > Work offline". Traffic ends.

[Bzbarsky (bzbarsky)]

Daniel, is that an Ubuntu build or a mozilla.org build? If the former, can you please test the latter?

[Syskin (syskin)]

(In reply to comment #90)
> http://www.videovalvonta.fi/control/faststream.jpg?html&stream=full

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?

[Bugzilla-kabsi (bugzilla-kabsi)]

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:1.9.0.1) Gecko/2008071719
  Ubuntu/8.04 (hardy) Firefox/3.0.5

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

The problem does not exist in an mozilla.org 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.

[Mh+mozilla (mh+mozilla)]

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

It means you have upgraded firefox, but not xulrunner-1.9.

[Bzbarsky (bzbarsky)]

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.

[Bzbarsky (bzbarsky)]

Bug 473161 filed on the regression.

[Bugzilla-kabsi (bugzilla-kabsi)]

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 1.9.0.1+build1+nobinonly-0ubuntu0.8.04.2" installed.

Now I am also running

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

[Alexander Sack (asac)]

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.

[Zorin (zorin)]

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.

[Dveditz (dveditz)]

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.

[Bzbarsky (bzbarsky)]

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.