1612620 - "#1 Best Seller" badge on Amazon has blocky points (due to border painting incorrectly), on Fenix on Android with WebRender enabled

Status: VERIFIED FIXED

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

Description

[Daniel Holbert [:dholbert]]

Attachment: screenshot of bug

STR:

1. Visit an amazon page with a "#1 Best Seller" badge, like this one:
   https://www.amazon.com/gp/product/B07THHQMHM
   Or view this reduced testcase, created by the testcase-reducer addon:
   https://jsfiddle.net/dholbert/yrjpk8c2/

EXPECTED RESULTS:
The right edge of the badge should have a triangular "bite" taken out of it (the top and bottom corners should be pointy).

ACTUAL RESULTS:
The right edge is a weird blocky stair-step.

I get EXPECTED RESULTS in Chrome on Android, in Firefox Beta 68.5 on Android, and in all browsers on Desktop (including in RDM).

I get ACTUAL RESULTS in Fenix (Firefox Preview Nightly) on Android.

I'm filing this as a Layout bug for now, since the corners are drawn using a CSS border. This might be a graphics issue, though (?)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (should render as four colorful triangles)

Comment 2

[Daniel Holbert [:dholbert]]

In Fenix, testcase 1 renders as four squares instead of four triangles.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screenshot of buggy rendering of testcase 1 (on Fenix)

Comment 4

[Daniel Holbert [:dholbert]]

mozregression is a bit broken for geckoview right now (see bug 1612627), but I tracked down a few-day regression range using mozregression -n gve --launch [date].

Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=63a84cdf&tochange=3d4f93bf

(to track down the range -- the following command produces a run with "expected results" (triangles) on testcase 1:

mozregression -n gve --launch 2019-11-25
0:01.38 INFO: Downloading build from: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/cJtne7SDSkC2YLfcRROJ5g/runs/0/artifacts/public%2Fbuild%2Fgeckoview_example.apk
===== Downloaded 100% =====
0:02.97 INFO: Running autoland build built on 2019-11-26 00:31:37.222000, revision 63a84cdf

And this command produces a run with "actual results" (squares) on testcase 1:

mozregression -n gve --launch 2019-11-27
0:02.09 INFO: Downloading build from: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Y9QsVImcR7yRU6SNwmt6Gg/runs/0/artifacts/public%2Fbuild%2Fgeckoview_example.apk
===== Downloaded 100% =====
0:04.93 INFO: Running autoland build built on 2019-11-28 00:12:16.661000, revision 3d4f93bf

...and I just used the provided revision IDs to produce a pushlog by hand.

Comment 5

[Daniel Holbert [:dholbert]]

I'm betting the regression here is this change, enabling webrender for my hardware (a Pixel 3):

Wed Nov 27 18:34:59 2019 +0000 dc8e651817f44f9aa760c17f6d37f2b3ca1adf7b Kris Taeleman — Bug 1598477 - Enable Webrender for Pixel 3 and Pixel 3 XL. r=jnicol

Not sure how best to track that dependency. For now, I'm marking this as blocking the wr-android metabug.

Also, for the record -- this works correctly on my linux Nightly with webrender enabled. So it seems to be an Android-specific WebRender bug.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #5)

I'm betting the regression here is this change, enabling webrender for my hardware (a Pixel 3):

Wed Nov 27 18:34:59 2019 +0000 dc8e651817f44f9aa760c17f6d37f2b3ca1adf7b Kris Taeleman — Bug 1598477 - Enable Webrender for Pixel 3 and Pixel 3 XL. r=jnicol

I confirmed that this was the cause. If I force-disable webrender on my phone (gfx.webrender.force-disabled = true), then I start getting EXPECTED RESULTS.

Comment 7

[Daniel Holbert [:dholbert]]

I can reproduce the bug on a Pixel 2 device in a brand new install of Firefox Preview Nightly, too. This makes sense, since WebRender is enabled for both models (Pixel 2 and 3), according to the code that was modified in bug 1598477.

Comment 8

[Jamie Nicol [:jnicol]]

Thanks for the report, testcase, and using mozregression! Very helpful!

I tried mozregression myself using --pref "gfx.webrender.all:true", but unfortunately the bug seems to be present as far back as I can run it without it crashing on startup.

Playing around with the testcase, I can see that border-style: solid; works as intended, but border-style: dashed; and border-style: dotted; both fail: they paint the entire corner segment a single colour (of the anti-clockwise edge), rather than half-and-half. Perhaps an issue in cs-border-segment.glsl, hitting a GLES limitation not present on Desktop GL?

Comment 9

[Kris Taeleman (:ktaeleman)]

I can take a look at this if that's ok with you Jamie.

Comment 10

[Kris Taeleman (:ktaeleman)]

Running this in emulator with webrender enabled shows the 4 triangles as expected, running on device on Pixel 3 XL fails.

Comment 11

[Kris Taeleman (:ktaeleman)]

Attachment: Bug 1612620 - Fixing dashed/dotted border issue Android devices with Adreno.

On Adreno devices, the default shader behaviour is to use 32bit integers
in the vertex shader and 16bit integers in the fragment shader. This
causes issues in the border shader due to bitshifting with 16 bits. The
fix here is to only shift by 8 bits as the data can be represented in a
16bit integer.

Comment 12

[Kris Taeleman (:ktaeleman)]

Attachment: Bug 1612620 - Fixing dashed/dotted border issue Android devices with Adreno.

On GLES, the default shader behaviour is to use highp(32bit) integers
in the vertex shader and mediump(16bit) integers in the fragment shader. This
causes issues in the border shader due to bitshifting with 16 bits. The
fix here is to only shift by 8 bits as the data can be represented in a
16bit integer and forcing mediump in the vertex shader as well.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a2caf09a5e7c
Fixing dashed/dotted border issue Android devices with Adreno. r=jnicol

Comment 14

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/a2caf09a5e7c

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Is this something we should uplift to Beta for GV74?

Comment 16

[Kris Taeleman (:ktaeleman)]

No, this is webrender specific and Fenix 4.0+ with GV 74 will have webrender disabled by default, webrender will only be enabled on nightly.

Thanks for double checking!

Comment 17

[Diana Rus]

Hi, verified as fixed, managed to reproduce on build Firefox Nightly 200204 (Build #20351803) but not with the link for amazon but with https://jsfiddle.net/dholbert/yrjpk8c2/ - please check video.
Devices:

• Google Pixel 3a XL (Android 10)
• Google Pixel 3a (Android 10)

Fixed Build:

• Firefox Nightly 200319 (Build #20790605) GV: 76.0a1-20200317093640 - Fixed
• Firefox Nightly 200221 (Build #20520606 ) GV: 75.0a1-20200220093508 - Fixed