1393512 - Hard to move (drag) wide items like url bar in customize mode due to their size (change algorithm for determining drop point for wide widgets?)

Status: NEW

(Firefox :: Toolbars and Customization, defect, P3)

Description

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Follow up to bug #1387313

STR:
1. Open "Customize..." mode
2. Move mouse button on URL bar container
3. Catch URL bar container with with "hand" mode mouse cursor/pointer
4. Move it to right after some buttons (everything works)
5. Try moving it to left and see that it's impossible, moving other buttons works to get proper effect

Comment 1

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Looks like the left part of the URL bar container isn't draggable

Comment 2

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Attachment: screencast.mp4

Comment 3

[:Gijs (he/him)]

We calculate where you're dropping something based on the center of the item as it's being dragged. If you start dragging with the left-hand-side of the URL bar, your mouse will need to go off the side of the window in order to drag the urlbar such that its center is positioned near the left of the window. That's not possible if the window is maximized, like in the screencast.

A similar problem would occur if trying to drag the url bar from its right-hand-side to the far right of the navbar.

Off-hand, I'm not sure how to fix this. To fix it "properly" I think we'll need a substantially more sophisticated drag algorithm (e.g. moving what we consider the 'center' of the item for items > 100px wide or something based on the relative position of the mouse cursor in the window, so that as you drag further left we think the center is further left, and vice versa), which we don't really have time to do (plus, what would that be?). But a somewhat simpler solution might be to resize the item before "picking it up" so that it's not quite so wide when dragging the "placeholder" ish image. That will look a bit clunky, I expect, but it should behave better. Jared, what do you think?


FWIW, I also see other problems, where the search bar somehow becomes really wide and the url bar gets a 'reserved space' that is way too small. Maybe something else funny is going on. :-\

Comment 4

[Jared Wein [:jaws] (please needinfo? me)]

It looks like it's already dependent on where the cursor grabs these wide items.

For these wide items, could we change http://searchfox.org/mozilla-central/rev/5696c3e525fc8222674eed6a562f5fcbe804c4c7/browser/components/customizableui/CustomizeMode.jsm#1683 to use the position of 12px from the end of the item (dependent on direction of drag)? That should give the same UX as dragging a normal 24px wide toolbarbutton.

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

Looks like this has already been triaged to P4 by the team so I'm marking this fix-optional for 62 and 63.

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

Marking fix-optional for 64. We could still take a patch in 65.

Comment 7

[Pascal Chevrel:pascalc]

Updating tracking flags as we get closer to the 64 release.

Comment 8

[Neha Kochar [:neha]]

Bulk change for all regression bugs with status-firefox67 as 'fix-optional' to be marked 'affected' for status-firefox68.

Comment 9

[Tim Spurway [:tspurway]]

[bulk change 69 status -> --- b/c to stop re-triaging old regressions every release]

Triage Owners: please do not set release status tracking flags in new releases unless this bug will actually be worked on

Comment 13

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

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:Gijs, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 14

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.