1644749 - [wfh] Window options drop-down does not work after check/uncheck the Disable notifications from screen-share permission door-hanger

Status: NEW

(Firefox :: Site Permissions, defect, P3)

Description

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

Attachment: Screen-share-dropdown-issue.mp4

Affected versions:

Beta 77.0b8
Nightly 78.0a1(2020-05-21)

Affected platforms:

Windows 7

Preconditions:

• Flip privacy.webrtc.allowSilencingNotifications to true
• Flip privacy.webrtc.legacyGlobalIndicator to false

Steps:

1. Launch firefox and access: https://hangouts.google.com/
2. Start a video call.
3. Click on share screen.
4. In the share screen doorhanger check the "Disable notifications from Firefox while sharing" and select a window or screen to share.
5. Uncheck the "Disable notifications from Firefox while sharing" checkbox and click on the Window or Screen to share dropdown again.

Actual result:

The "Window or Screen to share" dropdown stop working after random check/uncheck the "Disable notifications from Firefox while sharing" checkbox. The issue is reproducible after few attempts.

Expected result:

The "Window or Screen to share" dropdown should work anytime.
See the video attachment for a better understanding.

Regression range:

It is a feature implementation regression.

Comment 1

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

I'm able to reproduce this using the old panel as well:

https://drive.google.com/file/d/1D8mxRQMFwyKBCM7osiNH78dChVyrOSGR/view?usp=drivesdk

So I suspect this is a panel bug.

Although, arguably, since we've changed the meaning of the checkbox, this is worse with the new feature set.

Comment 2

[Daniel Bodea [:danibodea]]

This issue was also reproduced in Windows 10 with Beta v79.0b5 so it appears to be a general Windows issue.

Comment 3

[Adam Stevenson [:adamopenweb]]

I think we need a regression range for this bug.

Assuming this has existed for some time in Firefox, I wouldn't block the updated sharing UI on this.

Comment 4

[Daniel Bodea [:danibodea]]

I'm not sure whether I can properly investigate this because the issue appears to be somewhat intermittent (see how it reproduces in bug video demo). Nevertheless, I have attempted to find this issue's regressor by stressing the panel for at least about 2 minutes each time before rendering it a good build. Anyway, these are my results:

2020-09-27T16:24:30.347000: DEBUG : Found commit message:
Bug 1604412 - Enable remote backbuffer GDI compositing r=jmathies,jld

This change adds new "remote backbuffer" logic when compositing without
HW acceleration on Windows (IE compositing through Cairo using the Win32
GDI)

A new piece of shared memory is created between the GPU process and the UI
process, and the GPU process sends requests to the UI process to first "borrow"
a properly-sized buffer to draw into, and then sends a "present" request to
tell the UI process to actually blit the buffer to the Win32 window.

This is needed for the GPU sandbox to work, since Windows rightly doesn't
allow the untrusted GPU process to directly draw the contents of a window
owned by the trusted UI process.

Differential Revision: https://phabricator.services.mozilla.com/D61370

2020-09-27T16:24:30.347000: DEBUG : Did not find a branch, checking all integration branches
2020-09-27T16:24:30.349000: INFO : The bisection is done.
2020-09-27T16:24:30.350000: INFO : Stopped

Do you think this might be a correct regressor? This investigation takes quite some time, but I will reattempt it if you consider it necessary.
Thank you!

Comment 5

[Daniel Bodea [:danibodea]]

I would like to promote this issue's severity considering that it is not as intermittent as to not be able to provide a regression range. Please revert the change if you believe it to be inappropriate.

Comment 6

[Alin Ilea, Desktop Test Engineering [pto until 01.09]]

Hi,
I am still able to reproduce the issue in latest Nightly 87.0a1 (2021-02-08), Beta 86.0b7 and Release 85.0.1 using Windows 10. Setting the flags accordingly.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:pbz, since the bug has high priority and recent activity, could you have a look please?

For more information, please visit auto_nag documentation.