1052779 - Clicking on Mac share icons does not get Firefox into focus

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Nils Ohlmeier [:drno]]

If Firefox uses my web cam, microphone or shares my screen I get the new sharing icons in the bar at the top. If I click on the Icon a dropdown menu appears. If FF is not in focus, or even worse the upper left corner of my FF window is covered by another program, clicking on "Control Sharing" brings up a pop-up in FF, but FF does not get back into focus. So the user actually does not notice, because the pop-up is hidden by the other application (so it is a pop-under now). On windows clicking on the share icon brings FF back into focus, so the user can notice the pop-up in FF. On Mac this does not work.

Comment 1

[Nils Ohlmeier [:drno]]

Maire, can you find the right owner for this?

Comment 2

[Maire Reavy [:mreavy]]

Florian, Marco -- I feel we need to add this to the firefox backlog with a target of uplifting to Fx33 (since Fx33 is affected).  Can one of you add it to the backlog?

Comment 3

[Florian Quèze [:florian]]

Attachment: WIP

Neil, the attached WIP correctly puts the browser window in the foreground, but unfortunately the doorhanger popup gets hidden automatically when the window is activated.

I have verified that the attached patch doesn't prevent the doorhanger from showing, and that it actually gets hidden.

You can easily verify this (without the attached patch applied) with these steps:
- start sharing the camera.
- put another window above the bottom of the browser window (so that the browser window isn't the foremost window, but the doorhanger area is still visible).
- click "Control Sharing" in the menubar indicator.
- Observe that the doorhanger is shown.
- Click on the dock icon to bring the browser window to the foreground; observe that the doorhanger is hidden.

I have verified that this behavior isn't caused by something in PopupNotifications.jsm by commenting out all the hidePopup calls it contains.

Do you happen to know which code is hiding the doorhanger popups attached to the browser window when it's activated from the dock?

Comment 4

[Neil Deakin]

activateApplication can return before activating the application, so you'll want to wait until the window is focused before showing the popup.

Comment 5

[Florian Quèze [:florian]]

(In reply to Neil Deakin from comment #4)
> activateApplication can return before activating the application, so you'll
> want to wait until the window is focused before showing the popup.

But is there a good reason for the popup to get hidden when the application is activated?

Comment 6

[Neil Deakin]

Popups get closed when you change the focus. You shouldn't actually be opening them while the application is not activated.

Comment 7

[Florian Quèze [:florian]]

Do we have a way to know that the application isn't active? (That's different from the window being focused; focusing the window only brings it to the front of the other windows from the same application.)

Comment 8

[Florian Quèze [:florian]]

Attachment: Patch v2

This version of the patch actually works.

Comment 9

[Florian Quèze [:florian]]

Attachment: Patch v2

Real patch v2.

Comment 10

[Marco Mucci [:MarcoM]]

Hi Florian, can you provide a point value and if the bug should be marked as [qa+] or [qa-] for verification.

Comment 11

[Neil Deakin]

Comment on attachment 8473050 [details] [diff] [review]
Patch v2

>+#ifdef XP_MACOSX
>+    if (browserWindow.document.documentElement.matches("window:-moz-window-inactive")) {

This should just check if Services.fm.activeWindow != browserWindow. Or, if you just want to check if any window is active, just compare activeWindow to null. I think the latter is more what you want here.

Comment 12

[Florian Quèze [:florian]]

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

Comment 13

[Ryan VanderMeulen [:RyanVM]]

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

Comment 14

[Liz Henry (:lizzard) (relman/hg->git project)]

Florian, did you want to nominate this for uplift to 33?

Comment 15

[Florian Quèze [:florian]]

(In reply to Liz Henry :lizzard from comment #14)
> Florian, did you want to nominate this for uplift to 33?

This is something we will want to uplift, yes, but I was waiting for the bug to be verified before requesting approval for aurora.

Comment 16

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Reproduced the original issue on Mac OS X 10.9.4 with Nightly from August 12.

Verified as fixed in latest 34 Nightly, on Mac OS X 10.9.4.

Steps to reproduce:
- ensured media.getusermedia.screensharing.enabled = true (by default on Nightly now)
- set media.getusermedia.screensharing.allowed_domains = queze.net
- opened http://queze.net/goinfre/ff_gum_test.html
- started Audio/Video/Screen sharing
- brought another window to the foreground covering the top left of the Nightly window
- clicked on the Mac OS top bar icon and selected "Control Sharing"
The Nightly window was brought back into focus with the sharing doorhanger displayed.
This also worked with Loop, where the Nightly window was also brought back into focus with the share  doorhanger displayed at the proper position in the Loop window.

Comment 17

[Florian Quèze [:florian]]

Comment on attachment 8473050 [details] [diff] [review]
Patch v2

Approval Request Comment
[Feature/regressing bug #]: bug 1037430
[User impact if declined]: Clicking "Control sharing" in the menubar sharing indicator may appear to do nothing if another application is focused. Mac-only.
[Describe test coverage new/current, TBPL]: On m-c, verified by QA.
[Risks and why]: Low, self-contained Mac-only new code.
[String/UUID change made/needed]: none.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/559fe257d838

Comment 19

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Verified also in the latest Aurora 33 (BuildID=20140826004003), using http://queze.net/goinfre/ff_gum_test.html, same as in comment 16, and the Aurora window was brought back into focus with the sharing doorhanger displayed.