Closed Bug 1444185 Opened 2 years ago Closed Last year

WebRender - Left side of master password prompt field cut off

Categories

(Core :: Graphics: WebRender, defect, P1)

x86_64
Windows 10
defect

Tracking

()

RESOLVED FIXED
mozilla64
Tracking Status
firefox64 --- fixed

People

(Reporter: Adrian.Tiefenbrunner, Assigned: emilio)

References

(Blocks 1 open bug)

Details

(Keywords: nightly-community)

Attachments

(6 files)

Attached image prompt.png
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20180308100121

Steps to reproduce:

Enable WebRender by flipping `gfx.webrender.all` to true in about:config.


Actual results:

Text input field in master password prompt was cut off.


Expected results:

Master password field should look similar to how it looks like without WebRender enabled --> not be cut off.
Looks good on Debian Testing (KDE, Radeon RX480).
Component: Untriaged → Graphics: WebRender
OS: Unspecified → Windows 10
Product: Firefox → Core
Hardware: Unspecified → x86_64
Version: 60 Branch → Trunk
Attached image Download dialog cut off
Same happens with the download dialog
See Also: → 1424177
Both cases still occur on the latest Nightly [61.0a1 (2018-03-24) (64-Bit)].
Attached image checkbox-cut-off.png
I also noticed that some other web elements on Bugzilla are cut off. Should I open a seperate bug for this?

Maybe it's a scaling problem? I have a 15.6" Laptop with a FHD display and use a custom scaling factor in Windows (124, because it's even) instead of the odd 125 Windows defaults to. This is required for other applications (even Windows system applications such as the device manager) to render non-blurry. Maybe that's the edge case?
Attached image select-cut-off.png
I can indeed reproduce the cutoff bugzilla checkbox on my windows 10 machine with a display scale of 124. 

My usual scale of 250 looked fine.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached image scaling-issue.png
Win10 1803 (GeForce GTX 1060), 2560x1440 (Dell U2515H)
display scaling: 100% looks good, 125% (recommended) is unsharp(?)
I wonder if this might be fixed by the patch on bug 1453953.
Assignee: nobody → emilio
I'm concerned we could get a ton of bugs that are dups of this when we go to Beta.  This is why I'm keeping this a P1.
Hey Emilio, do you think you're likely to start this soon?  Or shall I reassign?  (I'm trying to spread the Beta-blocker bugs across the team -- as much as it makes sense.  Thanks!)
Flags: needinfo?(emilio)
(In reply to Maire Reavy [:mreavy] Plz needinfo from comment #10)
> Hey Emilio, do you think you're likely to start this soon?  Or shall I
> reassign?  (I'm trying to spread the Beta-blocker bugs across the team -- as
> much as it makes sense.  Thanks!)

Yeah, I had asked for a windows loaner to try to reproduce and debug this, should get it tomorrow.
Actually I asked Johann for his Windows laptop before he left the office. I can repro the checkbox thing and the scaling issue, though not the original bug.

I had to play a bit with the resolutions to make it reproducible.

For my own reference (or whoever looks at this as well), I can repro the checkbox thing with:

 * Resolution: 1366x768
 * Scaling: 100%

And the scaling issue with the same resolution an 125% scaling.
https://crisal.io/tmp/checkbox-subpixel.html reproduces the checkbox issue pretty consistently.
Note that non-WR also shows different borders in that test-case, but not cropped. I bet we're just rounding slightly differently somewhere.
I haven't been able to reproduce the master password stuff though, does somebody still see that?
Flags: needinfo?(jan)
(In reply to Emilio Cobos Álvarez (:emilio) from comment #15)
> I haven't been able to reproduce the master password stuff though, does
> somebody still see that?

I can reproduce it using a 124 custom display scale like Gankro mentioned in comment 6. I can also repro the cut-off checkboxes on Bugzilla and on your test page at that scale.
At a 125 scale (or default 100 scale) I don't see any cut-off stuff.
Later I wanted to check if it's fixed with one of cpearce's snapping approaches: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6e4864fdffdbce1daeae0e326f841e4423542399
That build doesn't fix it for me.
Flags: needinfo?(emilio)
Emilio -- are you able to repro this and make progress, or are you stuck?  (Looks like Kats can repro.)
Flags: needinfo?(emilio)
I'll try a bit more before handing it off. I can repro the clipping of the checkboxes, and chances are that the root cause is the same, so fixing one should fix the other :)
To avoid trimming pixels at the top / left.

This makes it at least as good as non-WR, and fixes both the checkboxes getting
cut off and the master password field.
Comment on attachment 9013163 [details]
Bug 1444185 - More consistently round around fallback data.

Markus Stange [:mstange] has approved the revision.
Attachment #9013163 - Flags: review+
Blocks: 1495317
Flags: needinfo?(emilio)
Flags: needinfo?(jan)
Actually, this breaks a few reftests, so I may need to do bug 1495317 here...
Or fuzz them of course, but that's not as great, and some of the failures like layout/reftests/image-element/bug-463204-ref.html clearly show the problem Markus was pointing out...
Flags: needinfo?(emilio)
Hi Markus, so I tried your suggestion and here's the resulting try run:

  https://treeherder.mozilla.org/#/jobs?repo=try&revision=b992de233811fe27556fb57e8b3fc622df5a1fc3

Does that look right and the failures there look fuzzable to you? Or should I figure out whether I've messed up somewhere along the way?

The different transforms (context vs. DrawTarget) got me a bit confused, but I _think_ this is the kind of approach you were talking about.

Thanks in advance!
Flags: needinfo?(emilio) → needinfo?(mstange)
I haven't looked at the code yet, but we need to understand at least some of the reftest failures. I'd start with 640272.html.
Flags: needinfo?(mstange)
Just got back to this, and I couldn't reproduce those locally with devPixelsPerPx = 1... So I guess I need to do some logging on the try runs. Not sure if there's a better way to debug it than that, if there is please speak up :)
QA Contact: mreavy
That being said, the scaling around all that fallback stuff looks very dubious, I have yet to see when the scale is non-1, but I don't know why it'd be ok to paint with the unscaled offset...
Well, it gets scaled sometimes but not others...
Ok, I could repro with some of the moz-element tests.
QA Contact: mreavy
Pushed by emilio@crisal.io:
https://hg.mozilla.org/integration/autoland/rev/86cc3618811a
More consistently round around fallback data. r=mstange
https://hg.mozilla.org/mozilla-central/rev/86cc3618811a
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Depends on: 1497059
You need to log in before you can comment on or make changes to this bug.