1093793 - desktop call recipient declining incoming call leaves link-clicker's camera on

Status: VERIFIED FIXED

(Hello (Loop) :: Client, defect)

Description

[Dan Mosedale (:dmosedale, :dmose)]

Presumably a regression from bug 1073410.

Comment 1

[Jared Wein [:jaws] (please needinfo? me)]

Looks like we just missed a call to .reset within _handleCallTerminated

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8517212 [details] [diff] [review]
Patch

Review of attachment 8517212 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/components/loop/standalone/content/js/webapp.jsx
@@ -25,5 @@
>     * Homepage view.
>     */
>    var HomeView = React.createClass({
>      render: function() {
> -      loop.standaloneMedia.multiplexGum.reset();

I changed these to just `multiplexGum.reset()`. Dan, do you know why these weren't using the multiplexGum reference that is declared at the loop.webapp scope?

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #3)
> 
> I changed these to just `multiplexGum.reset()`. Dan, do you know why these
> weren't using the multiplexGum reference that is declared at the loop.webapp
> scope?

Almost certainly just an oversight.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 8517212 [details] [diff] [review]
Patch

Review of attachment 8517212 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me; thanks for doing this!  r=dmose

Comment 6

[Jared Wein [:jaws] (please needinfo? me)]

https://hg.mozilla.org/integration/fx-team/rev/ca180a35db49

Comment 7

[u279076]

(In reply to Dan Mosedale (:dmose) - not reading bugmail; needinfo? for response from comment #0)
> Presumably a regression from bug 1073410.

Which branches does this affect?

Comment 8

[Dan Mosedale (:dmosedale, :dmose)]

It's standalone code (i.e. a webapp) that happens to be store in mozilla-central.  We effectively always deploy from mozilla-central itself (i.e. Nightly), so the question isn't really meaningful in that form.  What exactly are you trying to decide?  

How to test? (Browser version won't matter at all, but you'll need to test against a server that has recent webapp bits.  The dev deploy is one such server).

If there's something that needs uplifting? (No)

Comment 9

[u279076]

Sorry for not being clear. I'm trying to decide if we should track this bug as a Loop blocker for Fx34.

Comment 10

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/ca180a35db49

Comment 11

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

https://hg.mozilla.org/releases/mozilla-aurora/rev/7e49e9a80a01

Comment 12

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

Comment on attachment 8517212 [details] [diff] [review]
Patch

Approval Request Comment
Landed on aurora per IRC with lsblakk with a=loop-only

Comment 13

[Catalin Varga [QA][:VarCat]]

Verified as fixed using:

FF 35.0b4
Build Id: 20141216120925
OS: Win 7 x64
 I've disabled the rooms to have the option to decline the incoming calls and after declining I've checked for existing processes that use the web cam device id.

Comment 14

[Paul Silaghi, QA [:pauly]]

Verified fixed FF 36b1 Win 7