Clicking on Mac share icons does not get Firefox into focus

VERIFIED FIXED in Firefox 33

Status

()

Firefox
General
VERIFIED FIXED
4 years ago
3 years ago

People

(Reporter: drno, Assigned: florian)

Tracking

34 Branch
Firefox 34
x86
Mac OS X
Points:
2
Bug Flags:
firefox-backlog +
qe-verify +

Firefox Tracking Flags

(firefox33 verified, firefox34 verified)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

4 years ago
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.
(Reporter)

Comment 1

4 years ago
Maire, can you find the right owner for this?
Flags: needinfo?(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?
Blocks: 1040061
Component: WebRTC → General
Flags: needinfo?(mreavy)
Flags: needinfo?(mmucci)
Flags: needinfo?(florian)
Product: Core → Firefox

Updated

4 years ago
Flags: needinfo?(mmucci)
Flags: needinfo?(florian)
Flags: firefox-backlog+
(Assignee)

Comment 3

4 years ago
Created attachment 8472270 [details] [diff] [review]
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?
Attachment #8472270 - Flags: feedback?(enndeakin)
Whiteboard: [sceensharing-uplift]

Comment 4

4 years ago
activateApplication can return before activating the application, so you'll want to wait until the window is focused before showing the popup.
(Assignee)

Comment 5

4 years ago
(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

4 years ago
Popups get closed when you change the focus. You shouldn't actually be opening them while the application is not activated.
(Assignee)

Comment 7

4 years ago
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.)
(Assignee)

Comment 8

4 years ago
Created attachment 8473049 [details] [diff] [review]
Patch v2

This version of the patch actually works.
Assignee: nobody → florian
Attachment #8472270 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8472270 - Flags: feedback?(enndeakin)
Attachment #8473049 - Flags: review?(enndeakin)
(Assignee)

Comment 9

4 years ago
Created attachment 8473050 [details] [diff] [review]
Patch v2

Real patch v2.
Attachment #8473049 - Attachment is obsolete: true
Attachment #8473049 - Flags: review?(enndeakin)
Attachment #8473050 - Flags: review?(enndeakin)
Hi Florian, can you provide a point value and if the bug should be marked as [qa+] or [qa-] for verification.
Iteration: --- → 34.2
QA Whiteboard: [qa?]
Flags: needinfo?(florian)
(Assignee)

Updated

4 years ago
Points: --- → 2
QA Whiteboard: [qa?] → [qa+]
Flags: needinfo?(florian)

Comment 11

4 years ago
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.
Attachment #8473050 - Flags: review?(enndeakin) → review+
https://hg.mozilla.org/mozilla-central/rev/feef56233cc6
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 34
Florian, did you want to nominate this for uplift to 33?
status-firefox33: --- → affected
status-firefox34: --- → fixed
Flags: needinfo?(florian)
QA Contact: florin.mezei
(Assignee)

Comment 15

4 years ago
(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.

Updated

4 years ago
Iteration: 34.2 → 34.3
QA Whiteboard: [qa+]
Flags: qe-verify+
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.
Status: RESOLVED → VERIFIED
status-firefox34: fixed → verified
(Assignee)

Comment 17

4 years ago
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.
Attachment #8473050 - Flags: approval-mozilla-aurora?
Flags: needinfo?(florian)
Attachment #8473050 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
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.
status-firefox33: fixed → verified

Updated

3 years ago
Whiteboard: [sceensharing-uplift]
You need to log in before you can comment on or make changes to this bug.