1102868 - WebRTC sharing indicator is dismissed after a 2nd instance from ff_gum_test.html is used to stop sharing.

Status: RESOLVED DUPLICATE of bug 881331

(Core :: WebRTC, defect)

Description

[Ada [:adalucinet]]

Reproducible on:
Firefox 34 beta 11 (Build ID: 20141120192249):
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
latest Nightly 36.0a1 (Build ID: 20141120030202):
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0

Steps to reproduce:
1. Launch Firefox.
2. Navigate to about:config, search for 'media.getusermedia.screensharing.allowed_domains' and add people.mozilla.org
3. Restart Firefox.
4. Navigate to https://people.mozilla.org/~fqueze2/webrtc/ff_gum_test.html
5. Click on Application button and share any given app.
6. Open a new window and repeat steps 4 and 5.  

Expected results: The WebRTC doorhanger is not dismissed.

Actual results: The WebRTC doorhanger is dismissed.

Note:
1. Also reproducible on Windows 8.1 64-bit, Mac OS X 10.9.5 and Ubuntu 14.04 32-bit.
2. Screencast: https://db.tt/m6dbNPYi
3. Encountered the same result if the 'Stop' button is clicked on any window.
4. Reproducible with any other test page from https://people.mozilla.org/~fqueze2/webrtc/ff_gum_test.html, besides Application option.

Comment 1

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

Step 3 isn't needed (no restart for allowed domains needed)

When I tested, if I closed the new window while sharing, the URLBar sharing indicator pops back.
It also re-appears if I select the original window, and doesn't disappear if I re-select the new window.

If it is visible in both, and I hit Stop on one, it goes away in the other until I give that window focus, when it re-appears.

Also, the top-of-screen notifier stays active always, and even if you've stopped it in one window and it's not visible in the other, clicking the top-of-screen indicator causes it to give focus to the window, pop up the sharing doorhanger, and put the icon in the URLBar.

Because of all this, I don't consider this a critical defect, just a regular edge-case bug.

Florian, any ideas what's going on?

Comment 2

[Ada [:adalucinet]]

Regression range (m-c):
Last good: 2013-03-01
First bad: 2013-03-02

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2013-03-01&enddate=2013-03-02

Comment 3

[Florian Quèze [:florian]]

(In reply to Alexandra Lucinet, QA Mentor [:adalucinet] from comment #2)
> Regression range (m-c):
> Last good: 2013-03-01
> First bad: 2013-03-02
> 
> http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2013-03-
> 01&enddate=2013-03-02

The relevant change in this range is bug 843971. And then it turns out QA had already found bug 881331 when verifying bug 843971 :-(. That bug even had a working patch, but it didn't get checked-in because it didn't have a test... and then later in bug 1085691, the SocialAPI-specific case of this bug got fixed.