Closed Bug 1894564 Opened 9 months ago Closed 9 months ago

Intermittent forms/textarea/ltr-scrollbar.html != forms/textarea/rtl-scrollbar.html | single tracking bug

Categories

(Core :: Layout: Form Controls, defect, P5)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
127 Branch
Tracking Flags:
Tracking Status
firefox127 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: dholbert)

References

Details

(Keywords: intermittent-failure, intermittent-testcase)

Attachments

(1 file)

Bug 1894564: Add an explicit scrollbar-color for textarea ltr/rtl scrollbar position reftests. r?#layout
48 bytes, text/x-phabricator-request
Details | Review

This is almost-entirely affecting linux1804-64-tsan, for what it's worth.

It looks like the test is a "not-equal" test (!=) which is trying to check that we draw the scrollbar tracks on opposite sides (inline-end) of an explicitly overflow:scroll textarea when it's rtl vs ltr. But the screenshot shows that the scrollbar tracks simply aren't drawing at all.

They don't draw at all on my system when I load the testcase directly, but that's because they're overlay-style I think.

I kicked off a Try run where I simply flipped the test expectation so as to intentionally trigger the reftest to fail, in order to see what the normal/intended rerndering looks like. It does indeed have the scroll tracks drawing as solid gray bars, like this:
https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/dwlOAk3iQcexr_z3rYTYTA/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

Given that this is intermittent, that suggests that there might be some sort of race condition that cause the tracks to fail to paint in some cases, I guess? (or to not paint in time for the reftest screenshot?) That's a bit odd.

See Also: → 1894445

This reproduces intermittently (like on the order of 1/40 runs maybe) in retriggers on pushes at least as far back as April 15, e.g. this is the oldest one I've caught so far:
https://treeherder.mozilla.org/logviewer?job_id=456778100&repo=autoland&lineNumber=6884

I'm not sure why we didn't hit it earlier; not sure if it's from some sort of recent infra change (that affects retriggers of old builds), vs. if this was just a latent low-frequency failure that we were susceptible to for a long time but didn't hit for a while out of sheer luck...

I'm suspicious that bug 1888460 might be related here; it changed which category of machine we use to run these tests, and it's in my guilty-pushlog-range as I've been backfilling repeats of test runs...

In any case, I suspect we can fix this by setting scrollbar-color in these tests, to ensure that the scrollbar tracks render with a non-transparent color.

That's seems to be required for the reftest to reliably pass on my local Ubuntu 22.04 system, too (i.e. for ltr-scrollbar.html to reliably fail-to-match rtl-scrollbar.html). On my machine, the scrollbar tracks render as rgb(254,254,254) (on the right edge of the ltr testcase, and on the left edge of the rtl testcase), so we barely pass the test, but only by the tiniest of margins. It would be much better to explicitly use a colorful scrollbar track to ensure that it shows up. Otherwise I imagine the track color comes from the system configuration.

(It's super weird that it would be variable on these test runners and only-occasionally-transparent, but not inconceivable I guess? Maybe there's some sort of race condition where we request the scrollbar track color from the system, and we're passing-vs-failing (using gray vs. transparent) depending on how that race condition shakes out.)

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

I'm suspicious that bug 1888460 might be related here; it changed which category of machine we use to run these tests, and it's in my guilty-pushlog-range as I've been backfilling repeats of test runs...

Here's a tight pushlog with 3 pushes, for bug 1888460 and the push before & after. I've spammed a bunch of retriggers of the tsan reftest task that includes this ltr-scrollbar.html testcase. Currently the results are pretty clearly pointing to this being a new issue as of bug 1888460 landing:
https://treeherder.mozilla.org/jobs?repo=autoland&searchStr=tsan%2Cr8&tochange=6f6f52f31d0ea3327cccb71a33a9fa0fc277e3c8&fromchange=a6c95ed12e514ccf3e43f7cf11dfa317ab376543

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

In any case, I suspect we can fix this by setting scrollbar-color in these tests, to ensure that the scrollbar tracks render with a non-transparent color.

(adding see-also for the bug that added these tests, which was just about which side the scrollbar ends up on. Therefore, adding a scrollbar-color is fine for these tests to serve as a regression test for that bug.)

See Also: → 556363

These reftests are just trying to verify that the scrollbar ends up on opposite
sides for a left-to-right vs. right-to-left textarea. They do that by means of
a not-equal reftest comparison, but that comparison fails if the system happens
to have transparent (or white) scrollbar tracks.

This patch simply forces an opaque and clearly-distinguishable scrollbar-color
for these textareas, to avoid this fragile/accidental dependency on system
characteristics.

(While I'm at it, I also linewrapped the 'style' attribute for readability and
to avoid making the lines too long in these testcases.)

Assignee: nobody → dholbert
Status: NEW → ASSIGNED

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

(It's super weird that it would be variable on these test runners and only-occasionally-transparent, but not inconceivable I guess? Maybe there's some sort of race condition where we request the scrollbar track color from the system, and we're passing-vs-failing (using gray vs. transparent) depending on how that race condition shakes out.)

My tentative guess at explaining this^ is that we might be losing focus occasionally (e.g. if some sort of system dialog/notification appears); and so we end up drawing scrollbar-tracks using the inactive-window color; and on this particular system configuration, that happens to be transparent (or white).
[EDIT: This^ theory is wrong, see comment 10 for more.]

See Also: → 1894565
Pushed by dholbert@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4d4315109619 Add an explicit scrollbar-color for textarea ltr/rtl scrollbar position reftests. r=layout-reviewers,emilio

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

My tentative guess at explaining this^ is that we might be losing focus occasionally (e.g. if some sort of system dialog/notification appears); and so we end up drawing scrollbar-tracks using the inactive-window color; and on this particular system configuration, that happens to be transparent (or white).

I tested this theory and disproved it in this Try run:
https://treeherder.mozilla.org/jobs?repo=try&selectedTaskRun=as0aWLglS7O2H5jTqOT8Sg.0&revision=f17883304daf49b76d7992876029be43574ca03f&searchStr=r6

In that try run (based off of current central, not including the scrollbar-color patch that just landed here), I added some printf logging to show the system color that ComputeScrollbarTrackColor returns; and I also made a note of whether we're asking the system for the active-window color vs. inactive-window color. (I use CSTC as an abbreviation for ComputeScrollbarTrackColor in the logging in some spots.)

On both "good" and "bad" test-runs, we seem to be using the active-window color -- but it's a different color. "good" test-runs show:

21:16:33     INFO - ****dholbert Entering ScrollbarDrawing::ComputeScrollbarTrackColor
21:16:33     INFO - ****dholbert About to use scrollbar styling for active window
21:16:33     INFO - ****dholbert CSTC taking return #3, returning color: rgba(0.764706, 0.768628, 0.768628, 1.000000)

https://treeherder.mozilla.org/logviewer?job_id=456904898&repo=try

"Bad" test-runs show:

21:33:35     INFO - ****dholbert Entering ScrollbarDrawing::ComputeScrollbarTrackColor
21:33:35     INFO - ****dholbert About to use scrollbar styling for active window
21:33:35     INFO - ****dholbert CSTC taking return #3, returning color: rgba(0.000000, 0.000000, 0.000000, 0.000000)

https://treeherder.mozilla.org/logviewer?job_id=456904657&repo=try

Note the logging shows that we're using styling for an "active window", and note the rgba(0,0,0,0) scrollbar track color there, i.e. transparent (vs. an opaque 76%-gray color in the "good" test-run).

We're using these same colors consistently throughout the log, too, from the earliest time that my printf output appears in the log. You can see this if you filter the parsed logs for dholbert to see all of my logging. So: the "bad" test runners are consistently using transparent scrollbar tracks, throughout the whole test-run, for some reason; it's not something that goes bad partway through the test-run.

https://hg.mozilla.org/mozilla-central/rev/4d4315109619

Status: ASSIGNED → RESOLVED
Closed: 9 months ago
status-firefox127: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 127 Branch

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

Note the logging shows that we're using styling for an "active window", and note the rgba(0,0,0,0) scrollbar track color there, i.e. transparent (vs. an opaque 76%-gray color in the "good" test-run).

We're using these same colors consistently throughout the log, too, from the earliest time that my printf output appears in the log. You can see this if you filter the parsed logs for dholbert to see all of my logging. So: the "bad" test runners are consistently using transparent scrollbar tracks, throughout the whole test-run, for some reason; it's not something that goes bad partway through the test-run.

I spun this off as bug 1895092; it seems to be related to some variability in what GTK theme is getting used on these runners.

Depends on: 1895092
See Also: → 1940394
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: