1641546 - Global Sharing Overlay's position can't be moved on linux and windows

Status: VERIFIED FIXED

(Firefox :: Site Permissions, defect, P1)

Description

[Negritas Sergiu, Desktop QA]

Affected versions

• 78.0a1

Affected platforms

• Ubuntu 18.04 LTS

Steps to reproduce

1. Engage in a videoconference call.
2. Observe the Global Sharing Overlay.
3. Move the Global Sharing Overlay on the screen.

Expected result

• Global Sharing Overlay can be moved anywhere on the screen.

Actual Result

• The Global Sharing Overlay can't be moved from it's initial position.

Regression range

• This is a recent regression.

Additional notes

• This issue occurred after the Global Sharing Overlay title bar was fixed.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Setting to P2, as vchin has given me feedback that we can enable the new indicator on Linux in a later release.

Comment 3

[Daniel Bodea [:danibodea]]

It appears that this issue is also reproducible in Windows, along with the Linux.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

This appears to be a regression caused by bug 1639997... the window features that I needed to set in order to get the tests to pass seem to cause this. Starting to investigate.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

So this is related to the fact that I added "popup=yes" to the feature string for the window. This prevents the indicator from pulling focus, which is necessary to make some tests pass (and is probably a good idea, accessibility-wise). Windows of type "popup", however, appear to have different rules on different OS's. In particular, on Windows and Linux, popup windows aren't draggable via -moz-window-dragging: drag;. They also have different minimizing / closing characteristics.

I think the right solution here is probably to remove the "popup=yes" bit, but also find a way of ensuring that the indicator window does not pull focus. I'm looking into that now.

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1641546 - Make sure alwaysontop windows don't pull focus when first opening on macOS. r?mstange!

Comment 7

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1641546 - Make the new WebRTC global sharing indicator a dialog instead of a popup. r?pbz!

Depends on D77503

Comment 8

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1641546 - Make sure alwaysontop windows don't pull focus when first opening on Windows. r?mhowell!

Comment 9

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1641546 - Make sure alwaysontop windows don't pull focus when first opening on Linux GTK. r?stransky

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1641546 - Add a regression test for alwaysontop windows pulling focus. r?mstange!

Comment 11

[Mike Conley (:mconley) (:⚙️)]

This has the added benefit of not causing the Picture-in-Picture player window to pull focus when it opens.

Comment 12

[James Teh [:Jamie] (away returning 3 Oct)]

(In reply to Mike Conley (:mconley) (:⚙️) (Extremely busy) from comment #11)

This has the added benefit of not causing the Picture-in-Picture player window to pull focus when it opens.

That could be a problem for a screen reader user. While the sharing indicator is essentially an alert notification, a user possibly wants to interact with the picture-in-picture window. If a screen reader user activates picture-in-picture, they now won't get any indication that anything happened.

Comment 13

[Mike Conley (:mconley) (:⚙️)]

Hey Jamie,

Hm, okay, good point. Would it be sufficient to fire an "AlertActive" event manually for the Picture-in-Picture player window when it opens, like we do here for the WebRTC indicator?: https://searchfox.org/mozilla-central/rev/598e50d2c3cd81cd616654f16af811adceb08f9f/browser/base/content/webrtcIndicator.js#221-228

Comment 14

[James Teh [:Jamie] (away returning 3 Oct)]

(In reply to Mike Conley (:mconley) (:⚙️) (Extremely busy) from comment #13)

Would it be sufficient to fire an "AlertActive" event manually for the Picture-in-Picture player window when it opens, like we do here for the WebRTC indicator?: https://searchfox.org/mozilla-central/rev/598e50d2c3cd81cd616654f16af811adceb08f9f/browser/base/content/webrtcIndicator.js#221-228

I... never even knew about that event. 😳 Screen readers will ignore that unless the element has role="alert". But adding role="alert" to the PIP window feels wrong; it's not a notification.

I'd honestly prefer it continued to get focus, but I guess comment 11 suggests that non-screen reader users don't like this. (I guess for mouse users, focusing it doesn't serve any purpose because they can still interact with the window using the mouse?)

What about the keyboard shortcut? When people activate PIP with the keyboard, does it follow they want to interact with PIP using the keyboard, or is that not what users expect?

If we really don't want this to get focus, the only option I can come up with is to use A11yUtils.announce to tell screen readers something like "Picture-in-Picture window opened in the background." But I really don't like it.

Marco, any better ideas?

Comment 15

[Marco Zehe (:MarcoZ)]

Eek, no, because if an NVDA user activates the PIP window through the virtual cursor, it will simulate a mouse click, not a keyboard event. And most NVDA users will do it from the virtual buffer. I know I would. I wouldn't change fingers just to press the PIP keyboard shortcut. So if this never gets focus any more, an announcement is the only way we have to let screen readers know that this PIP window appeared. The old problem of focus having to be in more places than one, visual parallel processing vs. sequential speech/keyboard processing.

And no, we definitely don't want the PIP window to be an alert. Interacting with that would become cumbersome I think. Although it might be worth experimenting with it just to see if this assumption is accurate. But usual experience suggests it is.

Comment 16

[Mike Conley (:mconley) (:⚙️)]

Okay, thanks Jamie and MarcoZ. I guess what I'll do is land a separate patch in the PiP front-end code to make sure that the player window gets focus automatically upon opening to persist the old behaviour.

Comment 17

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1641546 - Focus the Picture-in-Picture player after it opens. r?mstriemer!

The other patches in this stack made it so that alwaysontop windows don't focus by
default when they open. We do, however, want the Picture-in-Picture player window to
take focus after it opens.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/041cd14e3893
Make sure alwaysontop windows don't pull focus when first opening on macOS. r=mstange
https://hg.mozilla.org/integration/autoland/rev/2dc2a430c2e7
Make sure alwaysontop windows don't pull focus when first opening on Windows. r=mhowell
https://hg.mozilla.org/integration/autoland/rev/a2b64d290c0b
Make sure alwaysontop windows don't pull focus when first opening on Linux GTK. r=stransky
https://hg.mozilla.org/integration/autoland/rev/4746c37be3e6
Add a regression test for alwaysontop windows pulling focus. r=mstange
https://hg.mozilla.org/integration/autoland/rev/72a62a455c47
Make the new WebRTC global sharing indicator a dialog instead of a popup. r=pbz
https://hg.mozilla.org/integration/autoland/rev/2652e1c084a7
Focus the Picture-in-Picture player after it opens. r=mstriemer

Comment 19

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/041cd14e3893
https://hg.mozilla.org/mozilla-central/rev/2dc2a430c2e7
https://hg.mozilla.org/mozilla-central/rev/a2b64d290c0b
https://hg.mozilla.org/mozilla-central/rev/4746c37be3e6
https://hg.mozilla.org/mozilla-central/rev/72a62a455c47
https://hg.mozilla.org/mozilla-central/rev/2652e1c084a7

Comment 20

[Cristina Coroiu [:ccoroiu]]

Backed out 6 changesets (bug 1641546) for permafailing browser-chrome at browser_devices_get_user_media_unprompted_access_tear_off_tab.js

Backout: https://hg.mozilla.org/integration/autoland/rev/c4dc5740defdf2888d7aadd20ceaf8b6dcb80ace

Failure push: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=2652e1c084a77120435b075939c36026b4811e69

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=305285060&repo=autoland&lineNumber=2223

Comment 21

[Mike Conley (:mconley) (:⚙️)]

Looking.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8b98bd961f10
Make sure alwaysontop windows don't pull focus when first opening on macOS. r=mstange
https://hg.mozilla.org/integration/autoland/rev/abb3f715d112
Make sure alwaysontop windows don't pull focus when first opening on Windows. r=mhowell
https://hg.mozilla.org/integration/autoland/rev/225dfac02102
Make sure alwaysontop windows don't pull focus when first opening on Linux GTK. r=stransky
https://hg.mozilla.org/integration/autoland/rev/c4aa2a4350d2
Add a regression test for alwaysontop windows pulling focus. r=mstange
https://hg.mozilla.org/integration/autoland/rev/85d2124732a3
Make the new WebRTC global sharing indicator a dialog instead of a popup. r=pbz
https://hg.mozilla.org/integration/autoland/rev/8d51c9b612ec
Focus the Picture-in-Picture player after it opens. r=mstriemer

Comment 23

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/8b98bd961f10
https://hg.mozilla.org/mozilla-central/rev/abb3f715d112
https://hg.mozilla.org/mozilla-central/rev/225dfac02102
https://hg.mozilla.org/mozilla-central/rev/c4aa2a4350d2
https://hg.mozilla.org/mozilla-central/rev/85d2124732a3
https://hg.mozilla.org/mozilla-central/rev/8d51c9b612ec

Comment 24

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 9152803 [details]
Bug 1641546 - Make sure alwaysontop windows don't pull focus when first opening on macOS. r?mstange!

Beta/Release Uplift Approval Request

• User impact if declined: An experiment to use the new WebRTC indicator will run with a semi-broken indicator.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: Bug 1642800
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The riskiest part is the change to the widget layer, but that's only for alwaysontop windows, for which there are only two kinds: the Picture-in-Picture player window (which is heavily tested in automation) and the new indicator (which is off by default).
• String changes made/needed: None.

Comment 25

[Julien Cristau [:jcristau]]

Comment on attachment 9152803 [details]
Bug 1641546 - Make sure alwaysontop windows don't pull focus when first opening on macOS. r?mstange!

approved for 78.0b6

Comment 26

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-beta/rev/b7d9f261e7ff
https://hg.mozilla.org/releases/mozilla-beta/rev/6791daf6242a
https://hg.mozilla.org/releases/mozilla-beta/rev/97e27f8a50b7
https://hg.mozilla.org/releases/mozilla-beta/rev/e7ae6bfb572a
https://hg.mozilla.org/releases/mozilla-beta/rev/41e941117d85
https://hg.mozilla.org/releases/mozilla-beta/rev/0f997e4424c1

Comment 27

[Daniel Bodea [:danibodea]]

This issue is now fixed in Nightly v79.0a1 and Beta v78.0b9. It does not occur on any of the main OSes. Thank you.