1005073 - WebRTC Permissions prompt on conversation window isn't shown if Firefox is in the background and then brought to the foreground

Status: RESOLVED WONTFIX

(Firefox Graveyard :: SocialAPI, defect)

Description

[Mark Banner (:standard8)]

STR:

1) Install a social provider with WebRTC (e.g. https://talkilla.mozillalabs.com)
2) Ensure Firefox is in the background
3) Have an incoming call
4) Bring Firefox to the foreground

Expected Results:

The permissions prompt is displayed

Actual Results:

Only the grey camera icon is displayed.


The permissions prompt in the url bar works just fine (tested with http://mozilla.github.io/webrtc-landing/gum_test.html)

Comment 1

[:shell escalante]

whiteboard tagged c= and p= to pull into scrumbugs

Comment 2

[Mark Hammond [:markh] [:mhammond]]

The problem here is:

* When a notification is opened for social, the social <browser> element (eg, the browser in the chat window) is passed - this is as expected.  The social window is not focused, so the notification isn't shown immediately but stashed away in a WeapMap.

* Later an "activate" event is fired, which is designed to display the previously stashed notifications.  The _update() method uses this.tabbrowser.selectedBrowser - which is *not* the same browser element above.

I'm not quite sure how to fix this - finding these "sub" browser elements seems tricky given the browser for the chat window is an anonymous node in an XBL binding.

However, I'm not sure on the priority of this given my understanding was that we want to avoid these prompts completely for loop (which would make this doesn't need to block the 'loop_mlp' bug.  Mark, can you clarify?

Comment 3

[Adam Roach [:abr]]

This bug is severely mitigated by the landing of Bug 1020451, since the browser will necessarily have focus as the result of the user clicking the "accept" button. There's still a window during which they can click away, but that's a rather narrow corner case.

Additionally, this bug goes away completely when Bug 1015486 is implemented, which should be pretty early in the MVP cycle. So I'm inclined to suggest that any work on this bug is wasted effort, in particular because this doorhanger behavior is "by design" (cf https://bugzilla.mozilla.org/show_bug.cgi?id=633179#c1).

Unless someone objects, I'm closing this as "WONTFIX" in the next several days.

Comment 4

[Mark Banner (:standard8)]

I agree with Adam, we don't need this for Loop as it has been mitigated.

However, I don't think this is necessarily WONTFIX as it would affect Social API providers who might want to use WebRTC.

Comment 5

[Shane Caraveo (:mixedpuppy)]

deprecation in fx51