Allow holding Ctrl/Cmd while creating a selection to move 1px by 1px

RESOLVED WONTFIX

Status

P3
enhancement
RESOLVED WONTFIX
3 years ago
3 months ago

People

(Reporter: ntim, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

We should be able to hold Cmd/Crl while creating a selection to make sure the selection only increments/decrements 1px for each mouse mouvement.
Created attachment 8669355 [details] [diff] [review]
Patch
Assignee: nobody → ntim.bugs
Status: NEW → ASSIGNED
Attachment #8669355 - Flags: review?(pbrosset)
Comment on attachment 8669355 [details] [diff] [review]
Patch

Review of attachment 8669355 [details] [diff] [review]:
-----------------------------------------------------------------

Forwarding this review to Matteo. He's a better reviewer than me for this.

Some questions though: Can you elaborate the use behind being able to move only pixel per pixel? Also, why bind both ctrl and cmd for this? Maybe we'd like to be able to constrain the width and height to be the same when you hold cmd in the future? Or something like this.
Attachment #8669355 - Flags: review?(pbrosset) → review?(zer0)
(In reply to Patrick Brosset [:pbrosset] [:pbro] from comment #2)
> Comment on attachment 8669355 [details] [diff] [review]
> Patch
> 
> Review of attachment 8669355 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Forwarding this review to Matteo. He's a better reviewer than me for this.
> 
> Some questions though: Can you elaborate the use behind being able to move
> only pixel per pixel? 
Well, usually, when creating a selection, the mouse might go too fast, and it's hard to get a pixel perfect selction. So, it would be nice if we could just hold a key to make sure the selection only increases pixel by pixel.

> Also, why bind both ctrl and cmd for this?
Cmd is usually the standard key for this kind of stuff on OSX. Ctrl is only for compat with other OSes.

> Maybe we'd like to be able to constrain the width and height to be the same when you
> hold cmd in the future? Or something like this.
Yeah, that could help with precision too, but I guess this is covered by bug 1152321. With that bug, I guess you'll be able to resize a selection from one side only.
(In reply to Tim Nguyen [:ntim] from comment #3)

> (In reply to Patrick Brosset [:pbrosset] [:pbro] from comment #2)
> > Comment on attachment 8669355 [details] [diff] [review]
> > Patch
> > 
> > Review of attachment 8669355 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > Forwarding this review to Matteo. He's a better reviewer than me for this.
> > 
> > Some questions though: Can you elaborate the use behind being able to move
> > only pixel per pixel? 
> Well, usually, when creating a selection, the mouse might go too fast, and
> it's hard to get a pixel perfect selction. So, it would be nice if we could
> just hold a key to make sure the selection only increases pixel by pixel.

So, currently for a more accurate measure you can zoom in (using the regular zoom control of the page) as you would have done in Photoshop as well. For the same reason, I'm trying to be consistent with well-known design tool about ux, and during selection those keystroke are used to have different effects (e.g. square selection, centered selection and so on).
I would leave the accuracy to the zoom, and given that the v2 of measuring tool permit to adjust the selection once is made, it should be enough; so we can leave the modifiers keys to the other common behavior.

If we want to have pixel perfection, we should probably do so giving the capability to input the coordinates directly as number – currently we do not have any UI for that, so we could modify the `measure` gcli command.

> > Also, why bind both ctrl and cmd for this?
> Cmd is usually the standard key for this kind of stuff on OSX. Ctrl is only
> for compat with other OSes.

In that case we usually check what is the platform and choose the appropriate modifier – also, sometime the ctrl key is used for something else in OSX.

> > Maybe we'd like to be able to constrain the width and height to be the same when you
> > hold cmd in the future? Or something like this.

Yeah, that something design tools usually does, and it's something I'd like more.

> Yeah, that could help with precision too, but I guess this is covered by bug
> 1152321. With that bug, I guess you'll be able to resize a selection from
> one side only.

So, bug 1152321 will give you the capability to resize the selection using the four corners; I was also thinking to implement arrow's keystroke to move the selection: using a modifier key, we could resize the selection pixel by pixel, that something I think it would be more consistent with the user experience – e.g. by default press arrow up will move the selection by -1px on y axis, but do the same with a modifier key could just reduce by -1px the height; where arrow down will usually move the selection by 1px on y axis, but with a modifier will reduce by -1px the height and move down by 1px.

What do you think?
Attachment #8669355 - Flags: review?(zer0)
Assignee: ntim.bugs → nobody
Status: ASSIGNED → NEW
The general behavior on Windows is:

While creation:
Ctrl: centered resizing
Shift: constrained sizing (i.e. width = height)

While editing:
Ctrl: contered resizing
Shift: constrained sizing (width/height factor stays equal)

And I fully agree with the points mentioned in comment 4 that pixel-perfect selections can be created by zooming the page or editing the selection afterwards.

So, I vote for WONTFIX on this one in favor of implementing the resizing features.

Sebastian
Component: Developer Tools → Developer Tools: Inspector
Inspector bug triage. Filter on CLIMBING SHOES.

Matteo, should we WONTFIX this?
Severity: normal → enhancement
Flags: needinfo?(zer0)
Priority: -- → P3
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(zer0)
Resolution: --- → WONTFIX

Updated

3 months ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.