Closed Bug 739557 Opened 12 years ago Closed 12 years ago

intermittent editor/libeditor/html/tests/test_dom_input_event_on_htmleditor.html | Editor4, html and div has contenteditable attribute: wrong element was edited - got , expected a

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla14

People

(Reporter: mak, Assigned: masayuki)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

Patch
2.66 KB, patch
ehsan.akhgari
: review+
Details | Diff | Splinter Review 
https://tbpl.mozilla.org/php/getParsedLog.php?id=10393524&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=10393091&tree=Mozilla-Inbound

21178 INFO TEST-PASS | /tests/editor/libeditor/html/tests/test_dom_input_event_on_htmleditor.html | Editor3, div has contenteditable attribute: input event by Redo wasn't trusted event
21179 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/html/tests/test_dom_input_event_on_htmleditor.html | Editor4, html and div has contenteditable attribute: wrong element was edited - got , expected a
21180 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/html/tests/test_dom_input_event_on_htmleditor.html | Editor4, html and div has contenteditable attribute: input event wasn't fired by 'a' key
21181 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/html/tests/test_dom_input_event_on_htmleditor.html | an unexpected uncaught JS exception reported through window.onerror - inputEvent is null at http://mochi.test:8888/tests/editor/libeditor/html/tests/test_dom_input_event_on_htmleditor.html:72
JavaScript error: http://mochi.test:8888/tests/editor/libeditor/html/tests/test_dom_input_event_on_htmleditor.html, line 72: inputEvent is null
OS: Windows 7 → Windows XP
Hardware: x86_64 → x86
Blocks: 668606
Hmm, it's strange. Why sometimes failed to set focus? (or to set caret position in the div element?)
Sometimes I've seen weird behavior when you focus the contentWindow of an iframe but not the iframe itself.  Could you please submit a patch to focus the iframe itself before focusing the contentWindow?
All of them failed at testing editor 4, I'll investigate it.
Depends on: 739927
Attached patch Patch — — Splinter Review 
I think that I misunderstood the Element.focus() behavior. It shouldn't work with non-editing host element. But the test sets focus to its window, that causes sometimes working fine. I'm still not sure why it fails randomly, however, I think that setting focus to the editing host and setting caret position by document.getSelection().collapse(), it works fine.

I tested on try server:
https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=1765e9b2e142
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Attachment #610470 - Flags: review?(ehsan)
Attachment #610470 - Flags: review?(ehsan) → review+
(In reply to TinderboxPushlog Robot from comment #37)
> philor
> https://tbpl.mozilla.org/php/getParsedLog.php?id=10480734&tree=Mozilla-
> Inbound
> Rev3 WINNT 5.1 mozilla-inbound pgo test mochitests-3/5 on 2012-03-29 12:29:47

This is before the landing.
(In reply to TinderboxPushlog Robot from comment #35)
> philor
> https://tbpl.mozilla.org/php/getParsedLog.php?id=10477412&tree=Mozilla-
> Inbound
> Rev3 WINNT 5.1 mozilla-inbound debug test mochitests-3/5 on 2012-03-29
> 10:10:45

This is also before the landing. If we saw this failure on m-i after now, the patch failed to fix this bug.
https://hg.mozilla.org/mozilla-central/rev/f059dc47f3d7
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: