1539091 - "Master Password Dialog" interrupts while reordering tabs. The drag operation is interrupted unintentionally

Status: RESOLVED DUPLICATE of bug 1538460

(Toolkit :: Password Manager, defect, P1)

Description

[Alice0775 White]

Reproducible: always

Steps to reproduce:

1. Make sure Master Password set

2. Logout web site(ex BMO)

3. Open web page(ex https://bugzilla.mozilla.org/ ) in background tab

4. Attempt to reorder tab
   Drag the background tab to the left or right

Actual Results:
Suddenly, "Master Password Dialog" pops up. And The drag operation is interrupted unintentionally.

Expected Results:
The drag operation should not interrupted.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9eab7d33fb582d01e005b4125894d35b6d8e7690&tochange=d16bf53b358583baa538e24697f85a597e4cf41c

Regressed by:
d16bf53b3585 Sam Foster — Bug 1149500 - Delay autofill until the document is visible. r=MattN

Comment 1

[Sam Foster [:sfoster] (he/him)]

Bug 1149500 made it so we defer showing master password prompt until the tab/document becomes visible (we listen for visibilitychange)

My understanding is that while we do expect tab warming to potentially happen as we mouseover each tab in the strip, this shouldn't cause a visibilitychange which would trigger the form autofill process to begin which causes the master password prompt to show.

So, I'll investigate a little to see what is actually going on.

Comment 2

[Sam Foster [:sfoster] (he/him)]

Turns out this only reproduces if the tab you want to drag is one which would require your master password. The other background tabs are not impacted. So, the mousedown that starts the drag also serves to bring the tab to the foreground and trigger the master password prompt to show.

I suspect we don't want to change the mouse-down-brings-background-tab-to-foreground behavior.

Detecting a tab drag is a little tricky - we don't currently keep any state that would say "this tab is in the process of being dragged". Technically, any mousedown on the tab starts a drag, we just abort handling it if the distance moved was below some threshold. However, finding a way to wait for the drag to end or mouseup to happen before processing the _onVisibleTasksByDocument in LoginManagerContent.jsm is one potential direction to take.

Comment 3

[Matthew N. [:MattN]]

An idea which probably won't work… does window.requestIdleCallback start an idle period while the user is dragging the tab?

From the spec

The user agent is in a better position to determine when background tasks can be run without introducing user-perceptible delays or jank in animations and input response, based on its knowledge of currently scheduled tasks, vsync deadlines, user-interaction and so on.

I'm guessing that we don't consider tab drags as a time when we're not idle especially since they're in a different process than the content but it could be worth a try.

Comment 4

[Pascal Chevrel:pascalc]

Sam, do you have an update on this 67 regression?

Comment 5

[Sam Foster [:sfoster] (he/him)]

(In reply to Pascal Chevrel:pascalc from comment #4)

Sam, do you have an update on this 67 regression?

:pascalc, I have a patch in progress. Most of the work is being done in bug 1538460. It may turn out we can dupe this bug to that one, but I'll need to confirm.

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #3)

An idea which probably won't work… does window.requestIdleCallback start an idle period while the user is dragging the tab?

:MattN tried that it doesnt help unfortunately.

I'm currently trying to round out the approach outlined in https://bugzilla.mozilla.org/show_bug.cgi?id=1538460#c24

Comment 6

[Sam Foster [:sfoster] (he/him)]

This and bug 1538460 share the same root cause, and the fix for this regression is the same so I'm duping them.