1740338 - Dragging tab header out from a Firefox window fails and makes tab header unresponsive if raced with getUserMedia

Status: RESOLVED DUPLICATE of bug 1544167

(Firefox :: Site Permissions, defect)

Description

[Back Aug 24 [:jib]]

STRs:

1. Open https://jsfiddle.net/jib1/pz5pynyf/ as a second tab.
2. Click "Allow" in the permission prompt if you get one (this primes the 60-minute permission grace period)
3. Refresh the page ↻ and then while the page is loading, in one swift motion, drag the tab heading downward and release to create a fresh window.

Expected result:

• Tab becomes a new window.

Actualt result:

• Tab pops back to where it was, and doesn't want to be dragged again. It also refuses to be closed or dragged horizontally now.

Workaround:

• Clicking and dragging a different tab heading seems to snap it out of it.

Comment 1

[Stephen A Pohl]

I can't seem to reproduce this. Does this reproduce in Nightly for you? What about a new profile and/or safe mode?

Comment 2

[Back Aug 24 [:jib]]

It reproduces in Nightly for me in safe mode. Here's a screen recording (the timing seems to matter).

Comment 3

[Back Aug 24 [:jib]]

I attend a lot of video meetings in the browser, and I always drag them out into their own window, so I hit this a lot.

Comment 4

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:spohl, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[Stephen A Pohl]

Reassigning this in case this is already being tracked in the WebRTC audio/video component.

Comment 6

[Back Aug 24 [:jib]]

The only place I can think of where getUserMedia touches things that might interfere with tab headers would be in the front-end code for showing privacy indicators, permission prompts, and Site Permissions . Paul, any thoughts on what might trigger something like this?

Comment 7

[Emma Zühlcke [:emz]]

Can't reproduce on Ubuntu 21.10, Nightly 96.0a1 (2021-11-25) (64-bit). I'm not aware of any site permissions or site identity specific code that could trigger this.

jib, since you can reproduce, do you have time to run mozregression? Maybe we can find the change that caused this.

Comment 8

[Back Aug 24 [:jib]]

Update: this is not it. It's a bit finicky to reproduce... will trying again below. Please ignore.

23:23.38 INFO: Got as far as we can go bisecting nightlies...
23:23.38 INFO: Last good revision: 66013e166aa82f864889f51062944e5509f94b7c (2020-06-28)
23:23.38 INFO: First bad revision: 31fb4a2a69124b6a21e5d8f44a0407d489749407 (2020-06-29)
23:23.38 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=66013e166aa82f864889f51062944e5509f94b7c&tochange=31fb4a2a69124b6a21e5d8f44a0407d489749407

23:23.38 INFO: Switching bisection method to taskcluster
23:23.38 INFO: Getting mozilla-central builds between 66013e166aa82f864889f51062944e5509f94b7c and 31fb4a2a69124b6a21e5d8f44a0407d489749407
23:25.01 WARNING: Skipping build 66013e166aa8: Unable to find build info using the taskcluster route 'gecko.v2.mozilla-central.shippable.revision.66013e166aa82f864889f51062944e5509f94b7c.firefox.macosx64-opt'
23:25.01 WARNING: Skipping build 31fb4a2a6912: Unable to find build info using the taskcluster route 'gecko.v2.mozilla-central.shippable.revision.31fb4a2a69124b6a21e5d8f44a0407d489749407.firefox.macosx64-opt'
...
23:36.56 INFO: There are no build artifacts for these changesets (they are probably too old).

Comment 9

[Back Aug 24 [:jib]]

It's bug 1643032, specifically privacy.webrtc.legacyGlobalIndicator = false (I'm unable to reproduce with it set to true in nightly).

22.16 INFO: Got as far as we can go bisecting nightlies...
19:22.16 INFO: Last good revision: 10ad7868f3ca27cb90db9bd1d392ff4d7852a0cd (2020-06-11)
19:22.16 INFO: First bad revision: 9388507a8b1f5c1550a7941483333db77478056f (2020-06-12)
19:22.16 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=10ad7868f3ca27cb90db9bd1d392ff4d7852a0cd&tochange=9388507a8b1f5c1550a7941483333db77478056f
...
19:34.35 INFO: There are no build artifacts for these changesets (they are probably too old).

Comment 10

[Back Aug 24 [:jib]]

Setting component to match regressing bug for proper triage. Please override if this is incorrect.

Comment 11

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1643032

Comment 12

[Emma Zühlcke [:emz]]

Thanks! Could be related to Bug 1681564.

Comment 13

[Mike Conley (:mconley) (:⚙️) (PTO Aug 24-28)]

This may have been fixed by the patch for bug 1544167. What's likely going on here is that a drag session isn't being ended properly. Bug 1544167's patch made it so that when new windows open, drag sessions get cancelled. jib, are you still able to reproduce this?

Comment 14

[Back Aug 24 [:jib]]

I'm no longer able to reproduce, so this looks fixed. There's still a time-window (around ~1 second after ⌘+r) where the dragging action doesn't produce a new window, but the UI doesn't get stuck in a mode now like it used to.