1681564 - Cannot detach or close active tabs

Status: REOPENED

(Firefox :: Site Permissions, defect, P3)

Description

[kenny.trytek]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

I tried to detach the active tab in a browser window on an external monitor by dragging it away from the other tab in the window to the middle of the screen on the external monitor.

Actual results:

Nothing happened. I am unable to click/drag the active tab or close them. The 'x' is shown on the active tab, but clicking on it doesn't do anything. I can use Command+W to close the tab.

I did find that I can interact with inactive tabs in the same window, so I can click on the 'x' to close them or click/drag an inactive tab into a new window. After doing this action with one of the tabs, the others are "loosened up" and I can then interact with the active tab as expected.

Expected results:

The tab should have detached from the window and moved to its own window.

Comment 1

[Simona Badau, Desktop QA]

I can't reproduce this issue on my Mac OS X 10.15 machine using the latest Nightly 86.0a1 or Firefox 84. I can properly drag and drop tabs on the external monitor (onto the same monitor or on the primary one).

Kenny, please can you confirm whether you reproduce this issue using Firefox in safe mode or with a new profile?
http://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
http://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Comment 2

[Simona Badau, Desktop QA]

Closing as Resolved: Incomplete due to no update from the reporter. If anyone can still reproduce this issue, please feel free to reopen the bug.
Thanks!

Comment 3

[kenny.trytek]

Shoot, sorry for the lack of updates. I am able to reproduce this maybe 75% of the time if I open a link to a Google Meet on an external monitor in a window that has a couple other tabs open. The tab is created and sends the request to the server; while the Meet is loading, I immediately try to click/drag to detach the tab. If I wait until the page fully loads before the click/drag, I never encounter this problem.

I tried disabling all add-ons in the active profile, but that did not resolve it.

I was able to reproduce the problem using a new profile with the same tabs open, and I think I've narrowed the scope some. Initially, I was unable to reproduce the issue in the first five attempts, but realized I had not selected the "remember this decision" checkbox for the security notification to allow Meet to use my microphone and camera. After selecting "remember" for both the microphone and camera, I was able to reproduce the issue nearly every time.

I was also able to reproduce the issue in safe mode.

Comment 4

[Simona Badau, Desktop QA]

Kenny, thanks for the additional info!

I managed to reproduce this issue on Mac OS X 10.15 and on Ubuntu 18.04 on the latest Nightly 86.0a1, Firefox 85 beta 6, and on the latest release 84.0.2. I could not reproduce the issue on Firefox 78.6.1 esr.

Here are the steps that I used:

1. Launch Firefox with a new profile
2. Log to your Google account
3. Open a new tab and paste a link to a meeting (obtained through Google Meet)
4. When prompted for mic and video permissions, check the "Remember this decision" box
5. Drag the tab from the Firefox window
6. Repeat steps 3 and 4 several times (the issue is not 100% reproducible).

I tried to find a regression window, here is the regression pushlog that I got to:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=abbe9ba06396393497c9282b2fe5555e701e5ff8&tochange=cb7a25e7ece2fdd844594982e426cf8cd43e90bb

Comment 5

[Ryan VanderMeulen [:RyanVM]]

Bug 1643032 seems like the most likely culprit in that range.

Comment 7

[Marco Castelluccio [:marco]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #5)

Bug 1643032 seems like the most likely culprit in that range.

Jan-Ivar, can you confirm?

Comment 8

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

I'm able to reproduce, both with Meet, but also with a simpler camera+mic access fiddle https://jsfiddle.net/jib1/pz5pynyf/

Not only does that tab become undraggable and unmutable, but clicks on buttons near and around its url bar also don't register.

It doesn't repro super-reliably for me, so take this with a grain of salt, but these prefs seem required to repro:

privacy.webrtc.allowSilencingNotifications = true
privacy.webrtc.legacyGlobalIndicator = false

That is: I'm (so far) unable to repro with these set to any other values (these are the new defaults set by bug 1643032 which have since made it to release).

A couple of times, but rarely, I also got this error in browser console:

error in gIndicatorWindow.updateIndicatorState(): gIndicatorWindow.updateIndicatorState is not a function webrtcUI.jsm:828
    updateGlobalIndicator resource:///modules/webrtcUI.jsm:828
    updateIndicators resource:///modules/webrtcUI.jsm:672
    updateIndicators resource:///actors/WebRTCParent.jsm:179
    receiveMessage resource:///actors/WebRTCParent.jsm:171
    (Async: JSActor query)
    updateIndicators resource:///actors/WebRTCChild.jsm:488
    observe resource:///actors/WebRTCChild.jsm:118
    observe resource:///actors/BrowserProcessChild.jsm:38

Workaround: If I drag an adjacent (unaffected) tab to a new window, then the undraggable tab seems to snap out of it.

Comment 9

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

For the folks who are able to reproduce this reliably (I've been only able to reproduce it once over the past few minutes), are you able to reproduce it if you set privacy.webrtc.legacyGlobalIndicator to true in about:config?

Comment 10

[kenny.trytek]

Mike, I am able to reproduce the bug at around a 75% rate if I'm trying. Changing privacy.webrtc.legacyGlobalIndicator to true caused the buggy behavior to disappear. With that setting, I could not reproduce it at all. Changing the setting back to false caused the buggy behavior again 2 out of 3 tries.

Comment 11

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

Thanks, kenny. That and comment 8 sounds like pretty compelling evidence that the indicator is involved somehow.

I have another thing for you to try, if you have a second. The indicator window is actually opened, even when you're only sharing the microphone and camera, but it's hidden. It's only shown for those devices if the global mute toggles are enabled. I'm interested in knowing if the hiding of the indicator is involved here.

Can you go to about:preferences#experiment, and enable "WebRTC Global Mute Toggles", restart the browser, and see if you can reproduce?

Comment 12

[kenny.trytek]

I don't have an experimental section of the preferences, but I set the privacy.webrtc.globalMuteToggles to true in about:config, restarted the browser, and tried again. That showed a small global mute button detached from the tab, but I was still able to reproduce the buggy behavior. Is there a different setting I should try?

Comment 13

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

No, that's good information, and what I wanted to know - whether or not the hiding of the indicator is an issue. Thanks!

When reproducing it, did you notice whether or not the indicator opened while you were still dragging? Are you ever able to reproduce it if you time it so that the indicator opens either before or after you drag, but not during?

Comment 14

[kenny.trytek]

If I complete the drag before the indicator appears, then it succeeds and functions normally.
If I wait a little, and click to start the drag while the indicator is appearing, the click/drag doesn't register, and nothing happens.
If I start the drag before the indicator appears and hold it, then release after the indicator appears, the buggy behavior occurs.

Comment 15

[Emma Zühlcke [:emz]]

Mike, can you help to assess a priority here? Should we prioritize this bug or move it to the backlog? Since it's a regression of Bug 1643032, would you like to take it?
From reading the comments I get that this happens when the new webRTC indicator appears while tab dragging is in progress?