Open Bug 1373990 Opened 2 years ago Updated 2 years ago

One-off search buttons separators don't have the same width if DPI > 100%

Categories

(Firefox :: Search, defect, P3)

defect

Tracking

()

Tracking Status
firefox57 --- wontfix
firefox58 --- affected
firefox59 --- affected

People

(Reporter: itiel_yn8, Unassigned)

References

Details

(Whiteboard: [fxsearch])

Attachments

(4 files)

Attached image Screenshot DPI 125%
Environment:
Windows 10 x86, resolution set to 1920x1080, DPI 125%/150%/175% on a 24" monitor.

See attached screenshots.

STR:
1. Install Nightly
2. Set Windows DPI to anything higher than 100%
3. Open Nightly, start typing anything in the URL bar

AR:
Some one offs separators are wider than the others by 1-2px

ER:
All separators should have the same width under every DPI setting.


Note that the same applies to both location and search bar.
Attached image Screenshot DPI 150%
Attached image Screenshot DPI 150% #2
Attached image Screenshot DPI 175%
Whiteboard: [fxsearch]
These vertical separator lines are background-images with a width of 1px: https://dxr.mozilla.org/mozilla-central/rev/95543bdc59bd038a3d5d084b85a4fec493c349ee/browser/themes/windows/searchbar.css#179

So this looks like a problem with how Gecko scales background images on exotic DPIs.  Or maybe it's just the nature of drawing 1px vertical lines when the number of pixels per point isn't integral?  We might need someone who knows about that to help here.

We have a bug open about tweaking these separators, bug 1358677.  I don't think its fix will address this bug, though.  (Guessing it only involves changing `background-size: 1px auto` to `background-size: 1px 100%` or something, for the moused-over button and its previous sibling.)
Priority: -- → P3
(In reply to Drew Willcoxon :adw from comment #5)
> So this looks like a problem with how Gecko scales background images on
> exotic DPIs.  Or maybe it's just the nature of drawing 1px vertical lines
> when the number of pixels per point isn't integral?  We might need someone
> who knows about that to help here.

Hey Milan, is this something your team could investigate?
Flags: needinfo?(milan)
Something Markus can probably answer off the top of his head.
Flags: needinfo?(milan) → needinfo?(mstange)
(In reply to Drew Willcoxon :adw from comment #5)
> Or maybe it's just the nature of drawing 1px vertical lines
> when the number of pixels per point isn't integral?

Yes, if these lines are drawn using backgrounds. For backgrounds, pixel snapping always snaps *edges*: We take the left and the right edge of the "true" rectangle and round each edge to device pixels independently. The resulting snapped rect can be wider or narrower than the "true" rect depending on the rectangle's subpixel position. This is something you can't work around using backgrounds, unless you set your background size to something that's an integer multiple of a device pixel (which is tricky).

Borders are treated differently: We snap border widths to device pixels at reflow time. So border widths are always integer multiples of a device pixel, and its left and right edge always get snapped in the same direction.

So I recommend using a border here instead of a background, if that's possible.
Flags: needinfo?(mstange)
Summary: One-off search buttons separators don't have the same width if DPI > 100 → One-off search buttons separators don't have the same width if DPI > 100%
Thanks Markus.

#identity-box and #urlbar-display-box use this nice technique to show a border that doesn't extend all the way to the top and bottom:

> #urlbar-display-box {
>   border-inline-end: 1px solid var(--urlbar-separator-color);
>   border-image: linear-gradient(transparent 15%, var(--urlbar-separator-color) 15%, var(--urlbar-separator-color) 85%, transparent 85%);
>   border-image-slice: 1;
> }

We should be able to replace the background image with this.  See also bug 1358677.

https://hg.mozilla.org/mozilla-central/annotate/a6a1f5c1d971dbee67ba6eec7ead7902351ddca2/browser/themes/shared/identity-block/identity-block.inc.css#l62
See Also: → 1358677
You need to log in before you can comment on or make changes to this bug.