Open Bug 1844373 Opened 10 months ago Updated 10 months ago

Dragged tab movement stalls near original tab location since the drag thumbnail popup was enabled

Categories

(Core :: Widget: Gtk, defect, P3)

Firefox 96
Unspecified
Linux
defect

Tracking

()

Accessibility Severity s3
Tracking Status
firefox-esr102 --- wontfix
firefox-esr115 --- wontfix
firefox115 --- wontfix
firefox116 --- wontfix
firefox117 --- fix-optional

People

(Reporter: ke5trel, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: access, regression)

Attachments

(1 file)

STR:

  1. Open several tabs.
  2. Drag a tab and move the cursor just below the tab strip.
  3. Drag across the length of the tab strip several times without entering it.

Expected:
Dragged tab moves smoothly and continuously at all times, keeping up with the cursor.

Actual:
Dragged tab stops moving and stalls when passing near its original location, even though the cursor is still inside the drag movement zone. Passing over the tab strip corrects the dragged tab position.

Occurs with Wayland and XWayland.

Did not happen before the drag popup thumbnail was enabled.

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=08eb1047d841ce4f1fcee1595dc4ec7ed8cba8f5&tochange=28da4138ddff87ff0684b274db911cd4b602ac92

Likely regressed by Bug 1730533.

Issue does not occur with nglayout.enable_drag_images = false.

:stransky, since you are the author of the regressor, bug 1730533, could you take a look?

For more information, please visit BugBot documentation.

Flags: needinfo?(stransky)

I see the same issue but only if cursor leaves tab strip area. If cursor is moved on the same level as tabs it works fine. I expect it's related do D&D mechanism where we create new window if cursor leaves tab strip area. I guess it's somehow expected.

Flags: needinfo?(stransky)

When dragging a tab, #tabbrowser-tabs has 15px padding and -15px margin that captures drag events below the tab strip, allowing it to be more forgiving for accessibility. Tab dragging is expected to work reliably within this region and it mostly does, except for when the cursor is near the original location of the tab. The width of the deadzone is slightly larger than the width of the popup.

Keywords: access

I wonder if the tab rearrange area can be extended then and if that helps.

Priority: -- → P3
Accessibility Severity: --- → s3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: