Open Bug 1620094 Opened 9 months ago Updated 2 months ago

If a tab opens a download popup as you are moving it, you can't move or close any tab in the window.

Categories

(Firefox :: Tabbed Browser, defect, P3)

73 Branch
Desktop
Unspecified
defect

Tracking

()

Tracking Status
firefox-esr78 --- fix-optional
firefox79 --- wontfix
firefox80 --- wontfix
firefox81 --- wontfix
firefox82 --- wontfix
firefox83 --- fix-optional

People

(Reporter: salzmanmichael, Unassigned, NeedInfo)

Details

(Keywords: dupeme, regression)

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

Steps to reproduce:

  1. Open a Firefox window with lots of tabs.
  2. Open a new tab that will create a Download popup.
  3. Before the tab loads in and opens the popup, start dragging it sideways as if to reorder tabs. Don't release the tab until the download popup opens.

Actual results:

No tabs in the window can be moved or closed. There is also a visual glitch where the dragged tab appears to remain where it was at the moment the popup opened rather than snapping to the align with the other tabs.

Expected results:

When Firefox is restarted, the tab returns to its original position before dragging. It should return there without restarting Firefox.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Tabbed Browser

Has this worked in previous versions of Firefox?

Flags: needinfo?(salzmanmichael)
Priority: -- → P3

Would you please provide us with such a test link? (A link of a page that needs some time to load and then it creates the Download pop-up. I need to be able to reproduce it to confirm it. Also, it is requested that we find whether this is a regression of now. Thank you!

Otherwise, you could help by attempting to regress the issue yourself with an app called mozregression. (https://mozilla.github.io/mozregression/install.html)

Thank you for your contribution!

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression

Adding the QA Whiteboard [qa-regression-triage], but please remove it if more details are added and could be reproduced by us.

QA Whiteboard: [qa-regression-triage]

I can somewhat reproduce it, but for me tabs can be moved or closed when this happens.
The effects for me are:

  1. The tab is "stuck" at wherever it was when the download popup has appeared
  2. Almost all of the toolbar items are non responsive. The only responsive buttons in that state are the bookmark toolbar ones, the Home button and the Downloads button. All the rest don't respond to hovering, clicking, right clicking etc, but tabbing to them does actually work.
  3. When switching to other tabs (or opening new ones), the effects of #2 above are still present.

The only way I could find to fix it is to drag one of the tabs over it (or it over others), and then everything gets unstuck. Oh, and restarting the browser also fixes things, of course.

Nothing gets logged in the console when this happens.

The issue of the tab getting stuck goes way back, but I managed to get a regression range only for the issue where the toolbar items get stuck:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f5d99e9f3d7bf19c8a222db97bedc924da27fd58&tochange=ea7b55d65d76214f97aaae502d65cb26fc6f5659
2017-09-06 to 2017-09-07

(In reply to Brindusa Tot[:brindusat] from comment #5)

Adding the QA Whiteboard [qa-regression-triage], but please remove it if more details are added and could be reproduced by us.

An easy way to reproduce would be:

  1. Open many tabs
  2. In one of them open https://speed.hetzner.de/
  3. Tab to the 100MB.bin file, don't hit Enter yet
  4. Move your mouse over the current tab
  5. Hit Enter, and quickly drag the tab.

(This STR avoids having to quickly move the mouse over the tab after clicking the link, which by then the download popup will probably appear and the chance to drag the tab would be missed)

Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Ever confirmed: true

This issue appears to be related to the "Open File - Security Warning" pop-up that appears after downloading the file. Having this pop-up displayed will put Firefox in a state of freeze until the pop-up is confirmed or declined, on a "bad" build, compared to a "good" build, where the user can complete his tab drag, even outside the window, where he could have control over the new window, even before interacting with the pop-up.

Regression logs:

2020-08-07T03:41:08.612000: DEBUG : Found commit message:
Bug 1588975 - Replace ShellExecuteExW with mozilla::ShellExecuteByExplorer. r=aklotz,asuth

The launcher process turns on the `PreferSystem32Images` mitigation policy for
the browser process.  Since the mitigation policy is inherited, a process launched
by the browser process also has `PreferSystem32Images`.  If an application which
does not support `PreferSystem32Images`, such as Skype for Business, is launched
via a hyperlink, a custom uri, or a downloaded file, it would fail to launch.

Bug 1567614 fixed this issue by introducing `mozilla::ShellExecuteByExplorer` to
`nsMIMEInfoWin::LoadUriInternal`.  This patch introduces
`mozilla::ShellExecuteByExplorer` to two more places.

1. xul!nsLocalFile::Launch
This is invoked when a user opens a file from the Download Library, or a user
opens a downloaded file with the default application without saving it.

2. xul!nsMIMEInfoWin::LaunchWithFile
This is invoked when a user opens a downloaded file with a custom application
(configured in about:preference) without saving it.

*Why does this patch change worker.js?*

The mochitest dom/tests/browser/browser_test_new_window_from_content.js failed
if it was executed after dom/serviceworkers/test/browser_download.js in the
same batch.  This was because browser_download.js launched Notepad to open
fake_download.bin.txt, preventing a new window from being opened in the
foreground in browser_test_new_window_from_content.js.

The test browser_download.js can verify downloaded data without opening an
associated application.  So this patch adds the content-type to the response
header in order not to open Notepad on Windows.

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

2020-08-07T03:41:08.612000: DEBUG : Did not find a branch, checking all integration branches
2020-08-07T03:41:08.615000: INFO : The bisection is done.
2020-08-07T03:41:08.618000: INFO : Stopped

NI me if results appear incorrect or verification is needed.
Thank you for your contributions!

Hardware: Unspecified → Desktop
Flags: needinfo?(tkikuchi)

comment #7 (and, I assume, comment #0) seems to me like it refers to the "what do you want to do with this file" popup, not the "security warning" popup... Itiel, can you clarify?

Pretty sure this is a dupe - looks like bug 1496107 ? Given that's older, I don't think the regression window is accurate.

Flags: needinfo?(itiel_yn8)
Keywords: dupeme

(In reply to :Gijs (he/him) from comment #9)

comment #7 (and, I assume, comment #0) seems to me like it refers to the "what do you want to do with this file" popup [...] Itiel, can you clarify?

Yes, that's what I meant.

Flags: needinfo?(itiel_yn8)

Comment #0 indicates the original reporter used macOS, but bug 1588975 affected Windows only. I could also reproduce the situation described in comment #6. This happens before ShellExecute or ShellExecuteByExplorer is called, so this is not a regression from bug 1588975.

Flags: needinfo?(tkikuchi)
No longer regressed by: 1588975
You need to log in before you can comment on or make changes to this bug.