Closed Bug 1093793 Opened 5 years ago Closed 5 years ago

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

Categories

(Hello (Loop) :: Client, defect)

defect
Not set
Points:
2

Tracking

(firefox35 verified, firefox36 verified)

VERIFIED FIXED
mozilla36
Iteration:
36.2
Tracking Status
firefox35 --- verified
firefox36 --- verified

People

(Reporter: dmose, Assigned: jaws)

References

Details

(Keywords: regression)

Attachments

(1 file)

Presumably a regression from bug 1073410.
Looks like we just missed a call to .reset within _handleCallTerminated
Attached patch PatchSplinter Review
Assignee: nobody → jaws
Status: NEW → ASSIGNED
Attachment #8517212 - Flags: review?(dmose)
Iteration: --- → 36.2
Points: --- → 2
Flags: qe-verify+
Flags: in-testsuite+
Flags: firefox-backlog+
OS: Mac OS X → All
Hardware: x86 → All
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?
(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 on attachment 8517212 [details] [diff] [review]
Patch

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

Looks good to me; thanks for doing this!  r=dmose
Attachment #8517212 - Flags: review?(dmose) → review+
(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?
Flags: needinfo?(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)
Flags: needinfo?(dmose)
Sorry for not being clear. I'm trying to decide if we should track this bug as a Loop blocker for Fx34.
https://hg.mozilla.org/mozilla-central/rev/ca180a35db49
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Whiteboard: [fixed in fx-team]
Target Milestone: --- → mozilla36
Comment on attachment 8517212 [details] [diff] [review]
Patch

Approval Request Comment
Landed on aurora per IRC with lsblakk with a=loop-only
Attachment #8517212 - Flags: approval-mozilla-aurora?
Attachment #8517212 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
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.
Verified fixed FF 36b1 Win 7
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.