1102947 - Picking up element in Customization shifts position and layout of other elements

Status: NEW

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

Description

[Elbart]

Attachment: shift.mp4

When picking up an element int he right Customization-pane, and just move it a few pixel over any adjacent element, the logos, labels and/or position of most of the following elements shift 1px.

Dropping the picked element resets the positions.

Reproduced in Windows and Ubuntu.

Comment 1

[:Gijs (out for now; he/him)]

Does this reproduce on a clean profile?

Comment 2

[:Gijs (out for now; he/him)]

Can you please specify versions in the bugs you file? Both here and bug 1102938.

Comment 3

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

I can confirm this in the latest Nightly (64bit) on Windows 7 (64bit).
Second ling will go a few pixels down after you grab one button to move.

Comment 4

[:Gijs (out for now; he/him)]

(In reply to Virtual_ManPL [:Virtual] - (ni? me) from comment #3)
> I can confirm this in the latest Nightly (64bit) on Windows 7 (64bit).
> Second ling will go a few pixels down after you grab one button to move.

Are you using a non-100% dpi/zoom setting in Windows? Default profile?

I can't reproduce on Win10.

Comment 5

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

(In reply to :Gijs Kruitbosch from comment #4)
> Are you using a non-100% dpi/zoom setting in Windows?
No.

(In reply to :Gijs Kruitbosch from comment #4)
> Default profile?
No,
but I can reproduce it also with clean new fresh profile without any addons.
It's reproducible in Safe Mode too.

(In reply to :Gijs Kruitbosch from comment #4)
> I can't reproduce on Win10.
I'm on Windows 7 (64bit).

Comment 6

[:Gijs (out for now; he/him)]

I can only reproduce on the win7 classic theme, but not on windows 7 glass. I think there's a peculiar Core issue here, because if I log the coordinates of the buttons and their labels, they don't change.

The whole thing seems to be related to the translate() transform that we give the icons to allow there to be a 'space' to indicate where an icon will be dropped. When the whole thing is at rest (without dragging any items) I can reproduce just by giving e.g. the 'share this page' item style="transform: translate(0, 0)" which should of course have no effect at all. As noted, I don't see any differences in the sizes and positions at all (checking with getBoundingClientRect(), but the element has clearly shifted visually (by 1px) on the screen. I don't know why.

Milan, this feels like a graphics issue. Do we treat classic and win7 differently in terms of graphics backend (or does the backend function differently on non-glass or whatever) ? Any idea what might be causing the differences I'm seeing even though the items are still in the same place as far as CSS and the DOM is concerned?

Comment 7

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

Attachment: Graphics section from about:support.txt

(In reply to :Gijs Kruitbosch from comment #6)
> I can only reproduce on the win7 classic theme, but not on windows 7 glass.
Just FYI, I can reproduce it with Aero enabled theme.

Adding also Graphics section from about:support, so you can see which backends I'm using.

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

If this happens accelerated and not (since it happens in safe mode), if it is in graphics, it's in the platform independent code.  Could be some rounding off error.  Kats, thoughts?

Comment 9

[Kartikaya Gupta (email:[e-mail])]

I'm not really sure. The first guess is that the translate property changes layerization of the items and that causes the pixel shifts. I tried reproducing and I see a slight shift in the bottom row of icons (on my Windows 10 Surfacebook) but it looks different from the video so I'm not sure I'm seeing the same problem. Markus, maybe you know what's going on here?

Comment 10

[Markus Stange [:mstange]]

This probably happens because the icons and the labels aren't perfectly pixel-aligned, and pixel snapping makes different decisions before and after layerization. Pixel snapping happens with respect to a certain origin, and for a given element, its pixel snapping origin is the top left corner of the border box of the closest transformed ancestor element.

Matt, does our current code attempt to work around this? I know that for inactive transforms we have the "residual translation"; was the intention to use it for active transforms as well?

Comment 11

[Matt Woodrow (:mattwoodrow)]

(In reply to Markus Stange [:mstange] from comment #10)
> This probably happens because the icons and the labels aren't perfectly
> pixel-aligned, and pixel snapping makes different decisions before and after
> layerization. Pixel snapping happens with respect to a certain origin, and
> for a given element, its pixel snapping origin is the top left corner of the
> border box of the closest transformed ancestor element.
> 
> Matt, does our current code attempt to work around this? I know that for
> inactive transforms we have the "residual translation"; was the intention to
> use it for active transforms as well?

residual transforms are computed as part of DefaultComputeEffectiveTransforms, so should apply to both active and inactive layers.

As Markus said, snapping is applied relative to the nearest transformed element.

For example, if you have two 0.4px offsets, then those would normally be snapped to 1px. Once a transform is added in between them, each 0.4px offset gets snapped to 0px separately, resulting in a different final position for the element.