1290111 - Camera icon still showing after close 47.0.1

Status: RESOLVED INCOMPLETE

(Core :: WebRTC: Audio/Video, defect)

Description

[Michael E]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160623154057

Steps to reproduce:

Closing the camera down programmatically.


Actual results:

Still leaves the camera icon showing to the left of the address bar. Users are able to click on the indicator that states the user is currently sharing their camera and or mic with this page, with the drop down showing continue sharing.     


Expected results:

Closing the camera down should remove the small icon to the left of the address bar too.

Comment 1

[Byron Campen [:bwc]]

If I'm not mistaken, that icon is there because the page still has access to the camera, if it so desires. jib, do I have this right?

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Michael E from comment #0)
> Steps to reproduce:
> 
> Closing the camera down programmatically.

Please include your code for stopping the camera, as I suspect there may be a problem there.

The following works for me, does it work for you? https://jsfiddle.net/016cvxjn/

Comment 3

[Michael E]

I can see by the example fiddle that the code shown removes both icons, however when tested in the project that I’m working on the bug remains. 

I appreciate that my code is the problem, but if I’m able to successfully close down the camera programmatically why is only the address bar camera icon remaining when the camera is clearly off. Selecting the “continue sharing” in the drop down doesn’t reactive the camera, but selecting “stop sharing” does remove the camera icon from the address bar.
  
My main concern is that users upon seeing the camera icon could mistakenly think that the camera was still operating when it’s not.

Could this be just a permissions issue?

Comment 4

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

That does sound concerning. Is there any way you could create a minimal JS test case based on the part of your code that interacts with the camera? If so that might help us reproduce it and fix it. Permissions shouldn't cause this.

Comment 5

[Michael E]

Fair request, however I think it’s fair to say that the problem is more at my end rather than with Firefox. So unless I’m able to provide a specific test case that you can test against perhaps it would be better that the case is closed.
 
Your fiddle does show that Firefox removes both icons which is the expected behaviour, so the job for me is to get my code to do the same. 

Appreciate all your help and effort.

Regards 

Michael E

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

(In reply to Michael E from comment #5)
> Fair request, however I think it’s fair to say that the problem is more at
> my end rather than with Firefox. So unless I’m able to provide a specific
> test case that you can test against perhaps it would be better that the case
> is closed.
>  
> Your fiddle does show that Firefox removes both icons which is the expected
> behaviour, so the job for me is to get my code to do the same. 

The important part you may be missing it to call .stop() on all tracks, not just make it available for GC.  If it's GC-able (all references gone), but stop() wasn't called, it will remain active until actually GC'd/CC'd (to test, provoke the behavior, and then in about:memory invoke GC and CC (or Minimize).  This assumes that you have no references to the stream/tracks left in your code or any objects.

Comment 7

[Michael E]

On starting a webrtc session in the about:memory after selecting Show Memory Reports > Measure.

Under Other Measurements – event-counts
 
I get the following appearing:-
top(chrome://browser/content/webrtcIndicator.xul, id=270)/active/window(chrome://browser/content/webrtcIndicator.xul)/dom

On ending the session and doing the same as above there is no reference to the webrtcIndicator in the report, however in my case there is still one appearing in the active window.

.stop() is being called on the tracks as per the fiddle, and I initially thought that not everything had been stopped also but the ICE state indicates closed.

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

No, you should end your call/test, then use the buttons to force a GC and CC (or Minimize) in about:memory.  No need to Measure.

However, if stop() has been called on all tracks, it *should* make the indicator go away.  Also please try with Nightly (51) or at least Developer Edition (should be 50 now).

You can also set the env variables NSPR_LOG_MODULES=timestamp,MediaManager:5,GetUserMedia:5 and NSPR_LOG_FILE=whatever.log, and upload the log file

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

> .stop() is being called on the tracks as per the fiddle, and I initially thought that not everything had been stopped also but the ICE state indicates closed.

ICE state has nothing to do with getUserMedia tracks, so that just tells you the peerconnection was closed/destroyed

Comment 10

[Michael E]

mediadevices.getusermedia if the user provides permission, then the returned promise is resolved with the resulting MediaSream object. A MediaStream consists of zero or more MediaStreamTrack objects, representing various audio or video tracks. So calling .stop() on all tracks stops the MediaStream which I’m doing, however why is it only one webrtcindicator being removed and not both.

The fiddle uses only one end point, but it’s hardly a real world example. Whether something remains in a real world test case that prevents the removal of the second indicator is something I’m trying to determine.
  
I’m of the opinion that not all webrtcindicators are signalling the MediaStream operating state, and the one that is remaining is only indicating getusermedia permissions. 

If I’m correct then consideration should be given to changing the indicator to something more appropriate rather than showing a camera which is misleading.
 
Anyway I’ll give what you have suggested a try and I’ll get back to you.

Cheers

Comment 11

[Michael E]

Tried the nightly 51.0a1 (2016-08-07) still the same, and on the logs I wont write what my boss said.

Appreciate that does make things difficult for you, but what I can tell you is that on the nightly the camera indicator in the none active tab pulses red and in the tab itself its amber.

Like the idea of the change in color of the indicator that could be the fix.

Comment 12

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Sadly, Nightly has a new pulsing red indicator that doesn't seem to be working right yet, so lets not get confused by that. I've filed bug 1294576 for it.

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

(In reply to Randell Jesup [:jesup] from comment #8)
> You can also set the env variables
> NSPR_LOG_MODULES=timestamp,MediaManager:5,GetUserMedia:5 and
> NSPR_LOG_FILE=whatever.log, and upload the log file

Please provide those logs so we can look further into this, thanks

Comment 14

[Nils Ohlmeier [:drno]]

Nothing actionable here.