Open Bug 1904705 Opened 8 months ago Updated 8 months ago

When dragging a bookmark folder onto itself, it creates a recursive alias rather than canceling the drag operation

Categories

(Core :: Widget: Gtk, defect)

defect

Tracking

()

Tracking Status
firefox-esr115 --- affected
firefox127 --- wontfix
firefox128 --- wontfix
firefox129 --- fix-optional

People

(Reporter: dholbert, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(3 files)

(Warning: these STR might cause (or get you closer to) a hang, per bug 1904682. I suggest running this in a fresh profile.)

STR:

  1. Ctrl+B to open Bookmark Sidebar.
  2. Click the > icon next to "Bookmarks Menu" to expand that folder.
  3. Click and drag the "Bookmarks Menu" folder-name around somewhere -- do not release your mouse button yet.
  4. Move the cursor back over the "Bookmarks Menu" folder and release your mouse cursor, to drop it back onto its starting location. (Let's say this is in an attempt to cancel the drag operation.)

[EDIT: this also repro's with the "Other Bookmarks" folder, which I use in alternate STR in comment 8 through 10.]

EXPECTED RESULTS:
No change. The drag-n-drop should be canceled.

ACTUAL RESULTS:
A new "Bookmarks Menu" folder (or alias) gets created, inside of the existing Bookmarks Menu folder. This is confusing and a dangerous step towards creating a recursive death-spiral (see bug 1904682).

Regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4eda9eb8926bdd50f4b80128ce3475eb7c6d9a4d&tochange=a3f0791a87fd3d2419768eff6da663361c9a3171

I see a few linux drag-and-drop commits in there:

ab39b9f4e86048db5cfb908af93019a31698ab8a stransky — Bug 1732116 [Linux] Use gdk_drag_context_get_actions() to get drop action, r=emilio
ea39b67162ebaa57d76259edaf3b998a76ea3663 stransky — Bug 1730203 [Wayland] Reply to drag_motion from Gtk handler, r=emilio
dfa8def985946c5a6670289f73acd23763ec316d stransky — Bug 1731197 [Linux] Make D&D operations more reliable and transfer only available D&D data types, r=emilio

I'm currently using Ubuntu 22.04 with Wayland. Haven't tested with Xorg yet, but I'll do so and check if this repros there as well.
I tested macOS and I canot reproduce there; macOS shows a green "+" icon over valid drop targets when I'm doing a drag-and-drop operation, and that green "+" disappears in step 4 of the STR here (and no nested folder-alias gets created when I drop).

stransky, would you mind taking a look?

Flags: needinfo?(stransky)

(Marking as blocking bug 1904682 since this makes that hang much easier to inadvertently trigger.)

Blocks: 1904682

(In reply to Daniel Holbert [:dholbert] from comment #0)

I'm currently using Ubuntu 22.04 with Wayland. Haven't tested with Xorg yet, but I'll do so and check if this repros there as well.

The bug reproduces under Xorg/X11 on the same system as well, so it's not wayland-specific. I get the same regression range as quoted in comment 0 when testing with Xorg/X11, too.

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

Given comment 3, this probably isn't a regression from bug 1730203 after all (since its commit message suggests it's a Wayland-specific change).
So: probably regressed by bug 1731197 or bug 1732116, but not sure which. (Either would be plausible to me, since one bug mentions querying for drag&drop targets, and the other mentions querying for drop actions; and both of those concepts seem relevant to what's going on here.)

(and I think we can call this wontfix for 127 and 128.)

Daniel, do I understand correctly this is reproducible on bookmark toolbar only? And it's not reproducible on Bookmark menu or bookmark titlebar?

Looks like we use explicit copy action on titlebar while other elements use move (you need to press CTRL on bookmark menu to do copy).
But even with the explicit copy I don't see the bug on bookmark menu/titlebar.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #7)

Daniel, do I understand correctly this is reproducible on bookmark toolbar only?

I can reproduce in all bookmarks UI.

This reproduces in:

  • The bookmarks sidebar (Ctrl+B)
  • The left "tree view" half of the "Manage Bookmarks" standalone window (aka the Library window, Ctrl+Shift+O)
  • The bookmarks toolbar.
  • The bookmarks titlebar-menu.

I'm now using the "Other Bookmarks" icon as my draggable thing, which I drop back onto itself to trigger the bug in all of these cases. In some cases you have to drag & drop that bookmark somewhere first (e.g. putting it inside the bookmarks toolbar) in another bit of UI in order to get it to show up so that I can test it in that UI.

I can add screencasts of the bug in these other pieces of UI later on today, if that's helpful.

Attachment #9409727 - Attachment description: screencast of first-bad vs. last-good Nightly, comparing with drag-and-drop for "Other Bookmarks" folder onto itself in various bookmarks UI → screencast of first-bad (right) vs. last-good (left) Nightly, comparing with drag-and-drop for "Other Bookmarks" folder onto itself in various bookmarks UI

Here's the case I forgot to include in the previous screencast, for the titlebar menu.

Note that here and in my previous screencast, I've set things up ahead of time by dragging the "Other bookmarks" folder inside of the "Bookmarks Toolbar" (in e.g. the history sidebar or Library window), to create an alias inside of the "Bookmarks Toolbar" menu; and that alias is the thing that I'm dragging-and-dropping here. (This is necessary in order to have a thing that can be dragged in all of the various bits of UI.)

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: