1741727 - Dragging a Firefox tab and letting go while over the Recycle Bin on Windows does not create a new Firefox window

Status: RESOLVED DUPLICATE of bug 1598915

(Firefox :: Tabbed Browser, defect)

Description

[Alex Hochheiden [:ahochheiden] [he/him]]

Steps to reproduce:

1.) On Windows, open a Firefox window and create at least two tabs.
2.) Position the Firefox window to cover a portion of the desktop, while still having the Recycle Bin visible on the uncovered portion.
3.) Drag any tab from the Firefox window to the Recycle Bin and release it.

Actual Results:
Dragged tab is returned to the origin Firefox window, and a new Window is not created.

Expected Results:
Tab should be transferred from the origin Firefox window into a newly created Firefox Window.

Additional Details:

Appears to be caused by: https://searchfox.org/mozilla-central/source/browser/base/content/tabbrowser-tabs.js#825

The dropEffect is a move (Just like dragging a file into the Recycle Bin "moves" it there), so this check causes an early exit without creating the new Window. Though, there may be unintended consequences of simply removing that check, which would need to be investigated.

Comment 1

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

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

For more information, please visit auto_nag documentation.

Comment 2

[Favour]

please is can i be assigned this bug

Comment 3

[Favour]

Hi, I am an Outreachy applicant interested in fixing this bug. I wish to take up this issue... could you pls guide me?

Comment 4

[Ekene Nwobodo]

I tried to reproduce this bug but it seems that it works just fine according to the expected result.
When I release the tab after dragging it to recycle bin, I get a newly created window of firefox and it is not returned to its origin window.
I only get this error in the terminal. Please verify is this bug is still valid

JavaScript error: chrome://browser/content/parent/ext-tabs.js, line 468: TypeError: can't access property "favIconUrl", tab is undefined
``

Comment 5

[Siya]

Hi Alex, looks like the link provided in the description of the bug points to code that has since moved. If that is the case, then could you please guide me as to where has it been shifted to? I would like to look into it. Thanks!

Comment 6

[Alex Hochheiden [:ahochheiden] [he/him]]

(In reply to Favour from comment #2)

please is can i be assigned this bug

You should just be able to hit Take button (to the right of Assignee at the top). Though, it looks like Siya plans to tackle this. In the future, I'd recommend utilizing the Request information from (also called needinfo) feature to increase your visibility, especially on older bugs. (It may have been a really long time before I saw your comment if Siya hadn't needinfo'd me).

(In reply to Ekene Nwobodo from comment #4)

I tried to reproduce this bug but it seems that it works just fine according to the expected result.
When I release the tab after dragging it to recycle bin, I get a newly created window of firefox and it is not returned to its origin window.
I only get this error in the terminal. Please verify is this bug is still valid

JavaScript error: chrome://browser/content/parent/ext-tabs.js, line 468: TypeError: can't access property "favIconUrl", tab is undefined
``

I can definitely still reproduce it, on Both Windows 10 and Windows 11, and both Firefox 111 and Firefox Nightly 113.0a1. To be clear, I'm talking about dragging a tab onto the Recycle Bin desktop icon (not into the File Explorer Window that shows up if you double click the Recycle Bin icon).

(In reply to Siya from comment #5)

Hi Alex, looks like the link provided in the description of the bug points to code that has since moved. If that is the case, then could you please guide me as to where has it been shifted to? I would like to look into it. Thanks!

I think this is the code I initially linked to, same file, just slightly further down: https://searchfox.org/mozilla-central/source/browser/base/content/tabbrowser-tabs.js#872

Comment 7

[Siya]

Attachment: Bug 1741727 - Dragging a Firefox tab and letting go while over the Recycle Bin on Windows does not create a new Firefox window. r=ahochheiden

Comment 8

[Siya]

Hey! So I've done the needful and have submitted a patch for the same marking you as reviewer. Kindly let me know if there is anything, I need to do further. Thank you.

Comment 9

[Alex Hochheiden [:ahochheiden] [he/him]]

While I did report the issue, I don't think I should review it (I don't work on the front-end of Firefox at all). The change looks good, I'm just not sure of all possible side-effects (it will probably change the observed behavior in bug 1417276, but not ultimately 'fix' it. What other interactions are there?).

I've added :dao as the reviewer, since they are the triage owner, and I'm unsure what review group this falls under.

Comment 10

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

This good-first-bug hasn't had any activity for 2 months, it is automatically unassigned.
For more information, please visit BugBot documentation.

Comment 11

[Dão Gottwald [:dao]]

(In reply to Alex Hochheiden [:ahochheiden] (needinfo? me) from comment #0)

The dropEffect is a move (Just like dragging a file into the Recycle Bin "moves" it there), so this check causes an early exit without creating the new Window. Though, there may be unintended consequences of simply removing that check, which would need to be investigated.

Sorry, I'm not normally on Windows and didn't have a chance to do a thorough investigation here, but I think it's reasonable to assume that this condition is there for a reason, and dropping it will likely have unintended side-effects. Would you be able to take a closer look on Windows, dragging a tab to various surfaces to see what the behavior is without and with this change?

I'll also remove good-first-bug here because it seems like a rather tricky bug even if the fix may be a one-liner, if we take it...

Comment 12

[Gregory Pappas [:gregp]]

this might be a duplicate of bug 1598915

Comment 13

[Alex Hochheiden [:ahochheiden] [he/him]]

(In reply to Gregory Pappas [:gregp] from comment #12)

this might be a duplicate of bug 1598915

I enabled the pref and tested it on Nightly and can confirm that this is resolved by bug 1598915.

Comment 15

[Ray Kraesig [:rkraesig]]

(In reply to Alex Hochheiden [:ahochheiden] (needinfo? me) from comment #13)

(In reply to Gregory Pappas [:gregp] from comment #12)

this might be a duplicate of bug 1598915

I enabled the pref and tested it on Nightly and can confirm that this is resolved by bug 1598915.

Oh no.

As the pref's name implies, it shouldn't have been necessary to enable it. It looks like I've left a ! out of the test-condition.