https://tbpl.mozilla.org/php/getParsedLog.php?id=8559822&tree=Mozilla-Inbound https://tbpl.mozilla.org/php/getParsedLog.php?id=8561661&tree=Mozilla-Inbound https://tbpl.mozilla.org/php/getParsedLog.php?id=8564240&tree=Profiling 19706 INFO TEST-PASS | /tests/editor/libeditor/text/tests/test_bug597331.html | Cursor should be moved correctly - 4 should equal 4 19707 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/text/tests/test_bug597331.html | The caret should be displayed correctly after reframing The reference image, which comes after t.focus(); t.selectionStart = 4; t.selectionEnd = 4; SimpleTest.executeSoon(); doesn't have a focus outline, the result image, which comes after t.style.display = 'block'; document.body.offsetWidth; t.style.display = ''; document.body.offsetWidth;, does have one. That must either be a horrible regression caused by bug 598482, or bug 598482 pointing out that the test needed to do something before taking the reference snapshot to ensure that there had been a flush to draw the focus outline. Or something :)

https://tbpl.mozilla.org/php/getParsedLog.php?id=8562493&tree=Mozilla-Inbound 19714 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/text/tests/test_bug600570.html | Pasting and setting the value directly should result in the same rendering Pretty much the same: the reference image comes from t.focus(); accel+A; and the result image comes after some cutting and pasting.

Try flushing before taking the reference screenshots.

Comment on attachment 588945 [details] [diff] [review] Patch (v1) So what you're really trying to flush is the focus state, right? I'd prefer you flush by getBoundingClientRect() on the textarea, in case we ever optimize flushing some... r=me with that change.

Try run for eac85c27fce7 is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=eac85c27fce7 Results (out of 1 total builds): exception: 1 Builds (or logs if builds failed) available at: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-eac85c27fce7

Hmm, this didn't help. Boris, do you have any other ideas?

Is the difference between the renderings really a focus outline, or is it some sort of antialiasing issue caused by different numbers of paints? Can we add some styles to the test to tell the two apart?

(In reply to Boris Zbarsky (:bz) from comment #42) > Is the difference between the renderings really a focus outline, or is it > some sort of antialiasing issue caused by different numbers of paints? Can > we add some styles to the test to tell the two apart? As far as I can tell from the data URLs in the log, it is the focus outline (the result image has a blue outline, the reference image has a gray one). Can you take a look to make sure that I'm not misinterpreting the renderings?

Oh, I saw the renderings in the log. What I don't know is whether the focus outline is expected to look like that.

(In reply to Boris Zbarsky (:bz) from comment #46) > Oh, I saw the renderings in the log. What I don't know is whether the focus > outline is expected to look like that. Yes, I think that's how foxued text boxes appear on Windows.

*focused!

Alright. So somehow we're failing to paint the focus outline for the reference.... That's pretty odd. I wonder whether we're ending up with retained layers that are not invalidated properly or something.... roc, can that happen in the new setup?

https://hg.mozilla.org/mozilla-central/rev/504046941435 (from m-i merge) Leaving open for Ehsan to figure out if this does fix the intermittent, or if its better to resolve and file a new orange bug, or whatever.