Closed Bug 1788320 Opened 2 years ago Closed 17 days ago

Intermittent editor/reftests/694880-1.html == editor/reftests/694880-ref.html | single tracking bug

Categories

(Core :: DOM: Editor, defect, P3)

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: jmaher, Unassigned)

References

Details

(Keywords: intermittent-failure, intermittent-testcase)

Attachments

(4 files)

reftest screenshot of the testcase (with unexpected vertical-bar)
17.25 KB, image/png
Details
patch with reftest-wait/MozReftestInvalidate that seems to make the issue reproduce 100% of the time
710 bytes, patch
Details | Diff | Splinter Review
testcase 1
419 bytes, text/html
Details
testcase 2
395 bytes, text/html
Details
No description provided.

Additional information about this bug failures and frequency patterns can be found by running: ./mach test-info failure-report --bug 1788320

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Severity: normal → S3

(drive-by analysis/notes, since I happened to hit this on a try run):

Here's a screenshot of what the testcase looks like in the failures (the ones I glanced at, at least). There's a vertical bar (a cursor/caret?) at the left edge of some green text; whereas the reference case doesn't have that vertical bar.

The testcase sets document.designMode to on and then off, with different text coloring rules applying for each state.

The fact that the testcase renders green (as shown in this screenshot) is an indication that we successfully got back todesignMode of off. But the vertical-bar is only supposed to show up when designMode is on. It's quite unexpected that we would ever paint a green vertical bar here, I think; the bar is a hint that designMode is on, but the text coloring indicates that designMode is off.

Odd, I cannot reproduce it on Windows and Linux even if I make ui.caretBlinkTime to -1.

When the document is loaded, designMode is set to on first. I think that at this point, HTMLEditor initializes Selection to collapse to end of the <body> because entire of the document is editable. Then, the <body> gets focus. Finally, setting designMode to off makes HTMLEditor clears the caret.

I wonder, the caret is not rendered because those things happen in an vsync period in normal use, but reftest frame work forcibly flush it immediately after ending the load event propagation? If so, removing reftest-wait class at next animation frame from the load event listener could fix this.

I thought this might help, but instead it seems to make the issue reproduce 100% of the time for me.

Attached file testcase 1 —

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #12)

Odd, I cannot reproduce it on Windows and Linux even if I make ui.caretBlinkTime to -1.

How about with the testcase I just attached? It reproduces the issue for me 100% of the time in Linux Nightly, if I load it with ui.caretBlinkTime set to -1.

It seems to be a combination of two things.
(A) a race condition to update the color and hide the caret (there's no reason we should ever paint a green caret here, since the green color is an indication that we've left designMode).
(B) a paint invalidation bug -- after reproducing the bug, if I e.g. alt-tab, then we do correctly repaint without the caret)

I think (A) is the proximal issue here. It's unclear whether (B) is really something wrong vs. just a downstream symptom of (A); the caret's not supposed to be there, so it's arguably correct that we're not invalidating its area after it should have been hidden (maybe?)

Actually, my attached testcase 1 reproduces the bug even if I leave ui.caretBlinkTime at its default value! I see the caret blinking on/off/on/off, until I do something to change focus (e.g. clicking somewhere, or alt-tab as noted above).

So: my guess was wrong in the previous comment, regarding paint invalidation. Alt-tab wasn't forcing a repaint there; it was simply causing a focus change.

Attachment #9301188 - Attachment description: testcase 1 (requires ui.caretBlinkTime to be set to -1 in order to trigger bug) → testcase 1
Attached file testcase 2 —

Here's a testcase where I've added the prefixed selectors to help this be testable further back.

With this one, I can confirm that I see this same issue at least as far back as Nightly 2011-01-01 (4.0 prerelease).

So: probably the reftest failure here is just a race, depending on whether we've managed to paint before the load event fires and the designMode tweaks get a chance to take effect. And we've gotten faster at getting that first paint in, which is why this started intermittently failing.

I spun off bug 1798379 for the underlying platform bug that goes back ~forever. In a perfect world we'd fix this intermittent by fixing that bug, but I'm not sure that's high-priority; so I've split out the platform bug, to allow us to use this bug here to track and potentially paper-over the intermittent (e.g. update the test's expectations to reflect reality) in the meantime.

Depends on: 1798379

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

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #12)

Odd, I cannot reproduce it on Windows and Linux even if I make ui.caretBlinkTime to -1.

How about with the testcase I just attached? It reproduces the issue for me 100% of the time in Linux Nightly, if I load it with ui.caretBlinkTime set to -1.

Yeah, I managed to reproduce this on Windows too, and thank you for investigating this!

https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup
For more information, please visit BugBot documentation.

Status: REOPENED → RESOLVED
Closed: 2 years ago → 4 months ago
Resolution: --- → INCOMPLETE

New failure instance: https://treeherder.mozilla.org/logviewer?job_id=481579763&repo=mozilla-beta

Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---

https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup
For more information, please visit BugBot documentation.

Status: REOPENED → RESOLVED
Closed: 4 months ago → 2 months ago
Resolution: --- → INCOMPLETE

New failure instance: https://treeherder.mozilla.org/logviewer?job_id=486512541&repo=mozilla-esr128

Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---

https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup
For more information, please visit BugBot documentation.

Status: REOPENED → RESOLVED
Closed: 2 months ago → 17 days ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: