1643503 - The new Camera/mic Global Sharing Overlay obscures Google Meet's camera/mic/leave-call buttons

Status: VERIFIED FIXED

(Firefox :: Site Permissions, defect, P1)

Description

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: MeetOverlap.png

Unfortunate placement.

Comment 1

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

Hey aaron - suggestions on what we want to do here?

Comment 2

[Aaron Benson]

Is the overlay placed at the bottom of the window or at the bottom of the desktop?

Comment 3

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

(In reply to Aaron Benson from comment #2)

Is the overlay placed at the bottom of the window or at the bottom of the desktop?

Bottom of the desktop, directly above any UI from the OS (like the Taskbar on Windows or the Dock on macOS).

Comment 4

[Aaron Benson]

I thought so, thanks for confirming.

In that case this seems like an unfortunate combination of screen size (e.g. a larger desktop wouldn't run into this) and the screenshare UI. Moving the overlay somewhere else is more than likely going to run into similar problems. Since the overlay is moveable and minimizeable, I think it's fine to leave as-is.

Related: Are we planning on adding telemetry on the overlay to get insight into it's useage? I'm mostly curious to know if it's a) frequently moved and/or b) frequently minimized.

Comment 5

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Note I double-clicked the Firefox window header to get it into this common maximized-but-not-full-screen macOs supported mode (I didn't carefully position it this way). It's also how maximized windows work in Windows, so it's going to be worse there.

I disagree this is fine as-is. We're placing our controls for camera and microphone where literally every WebRTC web-site places theirs. 🤦

Comment 6

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: WherebyOverlap.png

Comment 7

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: JitsiOverlap.png

Comment 8

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: MeetOverlapMoreDetail.png

(In reply to Aaron Benson from comment #4)

(e.g. a larger desktop wouldn't run into this)

What do you mean? These are all with default Macbook Pro 3360 x 2100 desktop resolution.

Perhaps you're confused by my sparse task bar? Here's one in max "More detail" display mode. Same problem.

Comment 9

[Aaron Benson]

What do you mean? These are all with default Macbook Pro 3360 x 2100 desktop resolution.

Perhaps you're confused by my sparse task bar? Here's one in max "More detail" display mode. Same problem.

Sorry, yeah, slight nuance there. Less to do with screen resolution and more to do with the maximized window.

We don't have enough information to know if this will be a problem for most people or not. We could consider moving it to another position (pinned centered and just below the browser toolbar, for example) but that will invariably cover up other UI at some point (either in the WebRTC UI or other tab that they could be sharing in a screen share).

Comment 10

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

We don't have enough information to know if this will be a problem for most people or not.

Maximizing a web conference window seems like a common enough use case for us to assume it will be a problem. We're covering up the most frequently used buttons of those apps (just from my own experience: self-mute whenever I'm not talking, quickly unmute when someone asks me a question, frantic audio+video mute before sneezing or child walks into the room on a recorded call etc.)

We could consider moving it to another position (pinned centered and just below the browser toolbar, for example) but that will invariably cover up other UI at some point (either in the WebRTC UI or other tab that they could be sharing in a screen share).

That's where it used to be, which has worked well for years except maybe on Linux Gnome where we have complaints (bug 1412116), so yeah there's no ideal placement for sure, except maybe on macOS where it's in the OS toolbar (where our new overlay is redundant BTW: double indicators).

Have we considered a design where the overlay is only present during screen sharing? That seems to be what Chrome is doing.

Comment 11

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

I think comment 10 is requesting information from aaron.

Comment 12

[Nils Ohlmeier [:drno]]

I must say that I agree with Jan-Ivar here: having camera and microphone share indicators at the bottom center is really terrible on Mac.

As a user I would try to find ways to turn this thing off or switch my browser. I consider this accidentally being placed so badly that it could result in Firefox loosing users.

Comment 13

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

As a user I would try to find ways to turn this thing off or switch my browser.

Does it not suffice that you can minimize it?

Comment 14

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

Attachment: sharing_indicator_-_02_-_camera.png

shorlander has given me a spec that changes the default vertical position offset and compacts the indicator. It also tries to make drag-ability more obvious.

Comment 15

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

Here's an interactive prototype from shorlander: http://stephenhorlander.com/sharing-indicator/sharing-indicator.html

Comment 16

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

Attachment: Bug 1643503 - Reduce minimum window dimensions for non-popup windows to 32x32 on macOS. r?mstange!

Comment 17

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

Attachment: Bug 1643503 - Compact the WebRTC global indicator to a height of 32px. r?pbz!

Depends on D79341

Comment 18

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

Attachment: Bug 1643503 - Offset the initial vertical position of the WebRTC indicator by 80px. r?pbz!

Depends on D79342

Comment 19

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

Attachment: Bug 1643503 - Make the WebRTC indicator's drag-ability more obvious, and update button styles. r?pbz!

Depends on D79343

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1bcaedf06fb9
Reduce minimum window dimensions for non-popup windows to 32x32 on macOS. r=mstange
https://hg.mozilla.org/integration/autoland/rev/b28d0c018553
Compact the WebRTC global indicator to a height of 32px. r=pbz
https://hg.mozilla.org/integration/autoland/rev/1f8dcaafb864
Offset the initial vertical position of the WebRTC indicator by 80px. r=pbz
https://hg.mozilla.org/integration/autoland/rev/a890be633ec3
Make the WebRTC indicator's drag-ability more obvious, and update button styles. r=pbz

Comment 22

[Narcis Beleuzu [:NarcisB]]

Backed out forbc failures on browser_parsable_css.js

Backout link: https://hg.mozilla.org/integration/autoland/rev/3f748d8b6ffb87fe6476895b08cbddec8fe5a420
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=306144077&repo=autoland&lineNumber=2136

Comment 23

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

Ooof - embarassing on my part. Fixed. Thanks!

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b9f6138e5565
Reduce minimum window dimensions for non-popup windows to 32x32 on macOS. r=mstange
https://hg.mozilla.org/integration/autoland/rev/48591e148b32
Compact the WebRTC global indicator to a height of 32px. r=pbz
https://hg.mozilla.org/integration/autoland/rev/a622eef2420b
Offset the initial vertical position of the WebRTC indicator by 80px. r=pbz
https://hg.mozilla.org/integration/autoland/rev/5251073544d4
Make the WebRTC indicator's drag-ability more obvious, and update button styles. r=pbz

Comment 25

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/b9f6138e5565
https://hg.mozilla.org/mozilla-central/rev/48591e148b32
https://hg.mozilla.org/mozilla-central/rev/a622eef2420b
https://hg.mozilla.org/mozilla-central/rev/5251073544d4

Comment 26

[Daniel Bodea [:danibodea]]

This issue does not occur anymore on the WebRTC web-apps that show the important control buttons right above the taskbar/dock/bottom and centered content area because the overlay now appears a bit above that area. Confirmed on all OSes.

Comment 27

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

Comment on attachment 9156030 [details]
Bug 1643503 - Reduce minimum window dimensions for non-popup windows to 32x32 on macOS. r?mstange!

Beta/Release Uplift Approval Request

• User impact if declined: Users put into the new WebRTC sharing indicator testing cohort will experience an older version of the 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: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): These tests mostly only change the indicator, which is preffed off on beta (but will be tested with a cohort of users). The only part that isn't restricted to that section of code is a small widget change on macOS to allow for smaller windows (32x32 rather than 60x60). This seems innocent enough.
• String changes made/needed: None.

Comment 28

[Julien Cristau [:jcristau] (back August 18)]

We're about to build 78 rc today, and 79 where this is already fixed will go to beta next week. It seems like this should wait for 79 and just ride the trains.