User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
Build ID: 20190529095015

Steps to reproduce

1. Create an event in Google Calendar. (Day/Week/Month view, it does not matter.)
2. Modify the browser width so as to change Calendar's flexbox size.
3. Observe the text of the event title.

Actual result

(Please refer to the attached screencast.)
At some widths the text clipping is more obvious than others.

Expected result

No text clippings.

Additional Notes

There is no text clippings if I disable WebRender.

about:support is attached.

Some desktop info
OS: Win10 1809 17763.529
VGA: Nvidia GeForce GTX 760
VGA driver: 430.64

What's your device pixel ratio? You can see your ratio here: https://www.mydevice.io/

Win10, GTX1060, Dell U2515H

Screen metrics
Size
    JS screen.width: 2560px
    JS screen.height: 1440px
    @media (device-width): 1920px+
    @media (device-height): 1366px+
Pixel ratio
    CSS pixel-ratio: 1
    JS pixel-ratio: 1.0000
Density
    Resolution (dpi): 96.00dpi
    Resolution (dppx): 1.00dppx
    Resolution (dpcm): 37.80dpcm
Misc
    Root font size: 16px
    Orientation: landscape
    Device Aspect-Ratio: 1.78

(In reply to Jeff Muizelaar [:jrmuizel] from comment #2)

What's your device pixel ratio? You can see your ratio here: https://www.mydevice.io/

Screen metrics

Size

JS screen.width : 1920px
JS screen.height : 1080px
@media (device-width): 1920px+
@media (device-height): 1080px+

Pixel ratio

CSS pixel-ratio: 1
JS pixel-ratio : 1.0000

Density

Resolution (dpi) : 96.00dpi
Resolution (dppx) : 1.00dppx
Resolution (dpcm) : 37.80dpcm

Misc

Root font size : 16px
Orientation: landscape
Device Aspect-Ratio : 1.78

I have reached this issue due to it's "regression-window-wanted" tag. Considering the fact that I don't really understand what the problem is here, I will try to request this information from the reporter, along with an explanation on how to do it.

Fanolian, Can you please try and regress this issue you reported? You can do that with an application created by mozilliens to determine which exact build introduced it. This app is mozregression; You can download it from here:
https://github.com/mozilla/mozregression/releases/download/gui-0.9.39/mozregression-gui.exe
(You also need python 2.7.15 (or 2.7.x) for it to work: https://www.python.org/ftp/python/2.7.15/python-2.7.15.amd64.msi)

Steps:

1. You have to determine a build that does not reproduce the issue.
   Considering that the 3 main version of the browser, firefox69, firefox68, firefox67 reproduces this issue, then you should probably look back to older versions and try to find one that does NOT reproduce it:
   a. Open mozregression-gui.exe
   b. Click "File" -> "Run a single build"
   c. On "Basic configuration" screen, select Build Type: "opt" and click "Next" button.
   d. Skip "Profile selection" screen by the "Next" button.
   e. In the "Single run wizard" screen, "Build from:" section, select "release" instead if "date" and then select a release number under 67.
   f. The mozregression app will open the selected build. Try to reproduce the issue and remember the release chosen.
   g. Repeat steps b. to e. until you find a build that does not reproduce the issue; Remember it.
   h. If even builds older than release 20 reproduce the issue, than you can consider this issue as not a regression and stop the investigation.
2. You will use mozregression app to "bisect" builds that reproduce the issue by builds that do not reproduce it in search of the one build/changeset that introduced the issue, in the first place:
   a. Open mozregression-gui.exe
   b. Click "File" -> "Run a new bisection"
   c. On "Basic configuration" screen, select Build Type: "opt" and click "Next" button.
   d. Skip "Profile selection" screen by the "Next" button.
   e. On the Bisection wizard screen, you will need to select a build that reproduces the issue and one that does not:
   e1. In the "Last known good build:" section, select "release" on the right drop-down and the release number that you found that does NOT reproduce the issue.
   e2. In the "First known bad build:" section, select "release un the right drop-down and a release number that you know to reproduce the issue, which are 68 or 67 or any other buiulds that you tested before and found to reproduce it (the earlier the build chose, the faster it will be to run the bisection).
   f. Click "Finish" to start the bisection process.
   g. builds will open one-by-one, you will need to test each one of them and see whether the issue reproduces. If it reproduces, then you need to select the "bad" button in the mozregression window and if not, you need to select the "good" button.
   h. When bisection is done, you will have the information in the "Log View" section of the mozregression window; bisection may also fail due to not enough builds, but the logs can always be usefull.
3. Copy the logs in a text file and attach it to this bug.

If there is still information you need regarding the regression process, please request information from me.
Alternatively, please explain exactly what this issue is and what is a situation where it would not reproduce and I will try to regress it myself.
Thank you for your contribution!

Sorry for the delay. I forgot about this bug.

Last good Nightly: 2018-09-19
First bad Nightly: 2018-09-20
pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9812141ec78239560283181ce610249d181b74b6&tochange=5347c7e4811a1a4d80bcee4119cead9192fdff69

Further bisection:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a1a0f861a0ae43b0a5668aa292e4705885ff19be&tochange=14c6b338e32c1da04218311b26e14cd2b9a3102b

This is regressed by bug 1492566.

Note:
This regression is about the clipping on the left (the left S) only.
There should be another clipping bug on the right but it is not introduced by bug 1492566. I need more time to investigate.

@jrmuizel, at 0:32 in the video in comment 0, the black box is overlapping the vertical grey line. Is it another bug? Thanks.

(I am marking Firefox67 as wontfix since this is a regression from 64.)

There should be another clipping bug on the right but it is not introduced by bug 1492566. I need more time to investigate.

Actually, to my layman's eye I do not think it counts as a clipping. Also I checked with WebRender disabled and it exhibits the same behaviour.

Andrew, do you want to take a look at this, see if you can reproduce, and perhaps make a reduced test case?

Bug 1574493 changed how clips got snapped quite a bit, before it was somewhat unpredictable how they would interact with an element. They should be consistent relative to each other now. I have been unable to reproduce thus far. Could you retry on current nightly? If you can still reproduce, can you confirm what font is selected? (Shift right click on the calendar entry, select inspect element, and hit the Fonts tab on the right hand side.) That may be important for reproducing. Thanks!

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0
20191007092954

I can still reproduce it on current Nightly. The font is the default web font Roboto Medium.

Thanks, I get the same font selected which is good :). I believe I have been able to reproduce after trying different zoom factors.

It isn't quite as severe, the S on the left is fine, and the S on the right is clipped too much.

I think I see the fix for this, at least to the extent I suffer from the problem. Build incoming for reporter to try out.

If this indeed is the fix, it won't be upliftable to 70 due to depending on bug 1574493. That would have fixed the problem if I did not make another mistake in using the incorrect origin point for the glyph offset calculations :). Hopefully this is the remaining root cause of the reported issue. I'll needinfo once the build is available.

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

Trimmed down a Google calendar page. This reproduces for me at 67% zoom (with my desktop at 200% scaling).

So my patch fixes it, but it breaks a ton of reftests as it changes the text positioning too much. Not snapping the text items doesn't work because it is a rounded clip in the clip chain that appears to be causing the problem, and it is a bit difficult to not snap all clips in the clip chain.

At this point there are a few things that are interesting:

1. We round the rect dimensions for rounded rect clips in display list building. This is wrong and will impede any fixes moving forward. This should be removed and any reftest failures investigated separately.

2. We snap text primitives in scene building just like any other. We should probably not do this. The rect and clip rect are very special, and the snapping doesn't actually change the glyph positioning at present. This may also impede a true fix like #2 and should be removed.

3. WebRender and non-WebRender appear to use different glyph spacing from each other. Comparing zoomed in rendering of the reduced test case shows that the S is actually translated one pixel to the left with WebRender. It seems plausible that this different positioning is not taken into account during layout when the rounded rect clip is generated in the item's clip chain, and as a result, it ends up being too tight and clips part of the S.

It turns out that item 3 in comment 18 is probably caused by several issues in the shader. Maybe I don't need the extra bug filed. This also seems to fix bug 1575258 as an additional bonus. The following try includes the shader fixes, as well as items 1 and 2.

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

This won't make 70, moving to 71

Is this fixed by your text snapping changes?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #21)

Is this fixed by your text snapping changes?

No. I had hopes but it did not.

This is happening on slack at 100% zoom and DPS of 1. Safe to assume this may be more widespread than initially thought. Currently the original reduced test case only reproduces at non-100% zoom and DPS of 1 for me. Bumping up priority to indicate I'm investigating.

Note that turning off overflow: hidden resolves the problems in both cases (which I did not note previously for the calendar), so this may not just be a case that our clips were snapped incorrectly relative to the content.

For the reduced test case and on Calendar site on my computer, the clipped left edge on the left S is fixed by bug 1575258, even with overflow:hidden enabled.

(In reply to Fanolian from comment #25)

For the reduced test case and on Calendar site on my computer, the clipped left edge on the left S is fixed by bug 1575258, even with overflow:hidden enabled.

And at different zooms? It breaks for me at 30% and 67% for example.

They are fixed too.

(In reply to Fanolian from comment #27)

They are fixed too.

Huh, that is very surprising. Thanks for following up. You already confirmed the font is Roboto Medium (same as me). I'm at least glad my other changes helped some configurations :). Hopefully the problem is merely moved around rather than more widespread.

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f6139293475370058f40e9df39956c42e3ba4244&selectedJob=278818751

This patch solves the Google Calendar and Slack text cut offs for me. Every failure in the push is an unexpected pass :D. Will go up for review once I write a wrench test case.

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

Rebased and fixed annotations (except maybe Android).

Snapping glyph positions are an internal detail to a primitive. As such,
any snapping required must be taken into account when calculating the
local rect. That ensures that when the clip is applied, it doesn't cut
off parts of the glyph that would have been retained after snapping.

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

Incorporates the fix for bug 1600237. Hopefully will be all green.

I may rewrite that test as a wrench test actually. It would make more sense probably...

This probably won't land before the soft freeze, but I would likely want to uplift very early in the beta cycle.

https://hg.mozilla.org/mozilla-central/rev/b5cfc7ed22b4
https://hg.mozilla.org/mozilla-central/rev/5ad40d4bd5a3
https://hg.mozilla.org/mozilla-central/rev/11e31e9d1c07

Can you help further and attempt to verify the fix that was pushed to Nightly?

(In reply to Bodea Daniel [:danibodea] from comment #43)

Can you help further and attempt to verify the fix that was pushed to Nightly?

It is fixed for me. Tested on 20191209215019. Thank you very much.

(For future reference: do remember turning off overflow: hidden when testing, especially when the text is small.)

Thank you!