u123541 Reporter
	Description • 10 years ago

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150112030201

Steps to reproduce:

Connect to any of my webcams.


Actual results:

Streaming video starts as expected.  However, when I close the tab, video continues to stream and FF ACKs it, wasting significant bandwidth.  I have to close the entire browser to stop the streaming.


Expected results:

Closing tab to webcam should close the connection and quit ACKing the stream.

	u123541 Reporter
	Comment 1 • 10 years ago

ARGH!!!  Where should I report this issue?  The same happens with konqueror, so it appears to be part of the IP stack...  BUT...  whatever it is, it keeps either browser from closing unless killed by root.

In both FF and konqueror, closing the app "completely" leaves a core hanging around. "fg"ing this remaining core, the stream continues, and Ctrl+Z pauses it.

Just my luck... anytime I find this type of bug, it's hard to find where to report it and I usually get to see lots of finger-pointing...  :/

Suggestions?

	:Gijs (he/him)
	Comment 2 • 10 years ago

(In reply to Pierre Fortin from comment #1)
> ARGH!!!  Where should I report this issue?  The same happens with konqueror,
> so it appears to be part of the IP stack...  BUT...  whatever it is, it
> keeps either browser from closing unless killed by root.
> 
> In both FF and konqueror, closing the app "completely" leaves a core hanging
> around. "fg"ing this remaining core, the stream continues, and Ctrl+Z pauses
> it.
> 
> Just my luck... anytime I find this type of bug, it's hard to find where to
> report it and I usually get to see lots of finger-pointing...  :/
> 
> Suggestions?

An actual URL to test with? :-)

"any of my webcams" doesn't really narrow it down.

	u123541 Reporter
	Comment 3 • 10 years ago

My cams are not publicly accessible.  They generate a TCP stream.  When the tab is closed, this stream continues.  

Trying to debug this further...  I set up a new userid and used FF in a virgin environment.  By itself, FF closes the stream; but I'm starting to investigate the various plugins.

Found that installing "Best Video Downloader 2 3.7" caused the stream to continue when I closed the tab.
However, I still need to test the other add-ons to see if this is the source...  there's a difference between this add-on's symptoms and what I see in my usual FF instance, so I'm not sure this add-on is the real culprit; although it does continue to receive.   However...

$ ps faux | grep pf3
root      7438  0.0  0.0  58276  1972 pts/20   S    09:04   0:00  |   \_ su - pf3
pf3       7444  0.0  0.0  14204  3612 pts/20   S+   09:04   0:00  |       \_ -bash
pf3      12280  0.0  0.0  12504  1412 pts/20   S    10:03   0:00  |           \_ /bin/bash -x /usr/local/bin/ff
pf3      12286  6.5  0.4 1136788 146816 pts/20 Sl   10:03   0:18  |               \_ /usr/local/bin/firefox/firefox
pf3      12349  2.6  0.1 528528 63636 pts/20   Sl   10:03   0:07  |                   \_ /home/usrlocal/bin/firefox37.0a1/plugin-container -greomni /home/usrlocal/bin/firefox37.0a1/omni.ja -appomni /home/usrlocal/bin/firefox37.0a1/browser/omni.ja -appdir /home/usrlocal/bin/firefox37.0a1/browser 12286 true tab

When I killed process 12349, the stream stopped.  I'm not familiar with the gory details of child processes; but is it not possible to force a child to terminate?  Otherwise, this would require staying on top of every add-on to prevent children from keeping streams going behind the scene...

More as I find it...

	Alice0775 White
	Comment 4 • 10 years ago

[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

I can reproduce the problem in Aurora37.0a2 and Nightly38.0a1 but not in beta36.0b2.

Steps to reproduce:
1. Open http://59.146.77.13/CgiStart?page=Single&Language=1
2. Close the tab
3. Open about:networking and refresh
   ---- observe Sockets and Received 


Actual Results:
Network would not stop after closing the corresponding tab 

Expected Results:
The network connection should stop immediately after closing the corresponding tab

	Alice0775 White
	Comment 5 • 10 years ago

Regression window(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/07c75e0d6f67
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0 ID:20150107013558
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/da5084c9e3e6
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0 ID:20150107013858
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=07c75e0d6f67&tochange=da5084c9e3e6


Regressed by: Bug 1112972

	Alice0775 White
	Comment 6 • 10 years ago

The problem happens new clean profile(no add-on installed).

Affected site:
http://59.146.77.13/CgiStart?page=Single&Language=1

	Alice0775 White
	Comment 7 • 10 years ago

And
http://www.mjpeg.net/webcams/17782

	Seth Fowler [:seth] [:s2h]
	Comment 8 • 10 years ago

I would bet with pretty high confidence that we are failing to cancel the channel when we close the tab. This is probably straightforward to fix, but I need to debug a little to figure out exactly where things are going wrong, because we *do* have code that is supposed to do that.

	Seth Fowler [:seth] [:s2h]
	Comment 9 • 10 years ago

I found the problem. This will be fixed by bug 1125401.

	Seth Fowler [:seth] [:s2h]
	Comment 10 • 10 years ago

This should be fixed on central now. Bug 1125401 still needs uplift to Aurora.

	Lawrence Mandel [:lmandel] (use needinfo)
	Comment 11 • 10 years ago

Dropping tracking as this issue was fixed in bug 1125401. Also marking 37 and 38 as fixed.

	Vasilica Tamas, QA [:vtamas]
	Comment 12 • 10 years ago

I was able to reproduce this issue on Firefox 38.0a1 (2015-01-23) using Windows 7 64bit.

Verified fixed on Firefox 39.0a1 (2015-03-12), Firefox 38.0a2 (2015-03-12) and Firefox 37 Beta 4 (20150309191715) using Ubuntu 12.04 32bit, Mac OS X 10.9.5 and Windows 7 64bit.