Open Bug 718316 Opened 13 years ago Updated 4 years ago

Intermittent test_bug597331.html | The caret should be displayed correctly after reframing and/or test_bug600570.html | Pasting and setting the value directly should result in the same rendering, where the reference image lacks a focus outline

Categories

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

Product:
Core
Component:
DOM: Editor
Platform:
x86
Windows 7
Type:
defect

Tracking

()

Milestone:
mozilla12

People

(Reporter: philor, Unassigned)

References

Details

(Keywords: intermittent-failure, Whiteboard: [tests disabled])

Attachments

(1 file)

Patch (v1)
1.80 KB, patch
bzbarsky
: review+
Details | Diff | Splinter Review
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.
Summary: Intermittent test_bug597331.html | The caret should be displayed correctly after reframing where the reference image lacks a focus outline → Intermittent test_bug597331.html | The caret should be displayed correctly after reframing and/or test_bug600570.html | Pasting and setting the value directly should result in the same rendering, where the reference image lacks a focus outline
Attached patch Patch (v1) — — Splinter Review
Try flushing before taking the reference screenshots.
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #588945 - Flags: review?(bzbarsky)
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.
Attachment #588945 - Flags: review?(bzbarsky) → review+
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.
Assignee: ehsan → nobody
(In reply to Boris Zbarsky (:bz) from comment #49) > 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? What new setup? I would think we'd have something filed on real-world sites for a bug that obvious, but I can't think of one. Are we sure focus isn't lost during the reframe somehow?
"The new setup" is bug 598482.
> What new setup? With invalidation off the refresh driver. > Are we sure focus isn't lost during the reframe somehow? The focus outline is present _after_ the reframe. It's not present _before_ the reframe. At least if we believe the screenshots...
Status: ASSIGNED → NEW
Daddy, is this where you keep your blog?
Whiteboard: [orange][tests disabled] → [tests disabled]
Couldn't you setup a listener for MozAfterPaint before calling focus on the textarea and then run the test after the event is received?
Blocks: 847885
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3

Bulk-downgrade of unassigned, 4 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Severity: normal → S4
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: