Closed Bug 665677 Opened 14 years ago Closed 13 years ago

Intermittent test_bug330705-2.xul | The first box element is still focused after blur() has been called on the second box element

Categories

(Core :: DOM: Events, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla15
Tracking Status
firefox-esr10 --- fixed

People

(Reporter: philor, Assigned: enndeakin)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file, 1 obsolete file)

http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-Inbound/1308597920.1308599553.32513.gz Rev3 Fedora 12 mozilla-inbound opt test mochitest-other on 2011/06/20 12:25:20 s: talos-r3-fed-059 1537 INFO TEST-START | chrome://mochitests/content/chrome/content/xul/content/test/test_bug330705-2.xul 1538 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/content/xul/content/test/test_bug330705-2.xul | The first box element is still focused after blur() has been called on the second box element 1539 INFO TEST-END | chrome://mochitests/content/chrome/content/xul/content/test/test_bug330705-2.xul | finished in 26ms
Attached patch Patch (obsolete) — — Splinter Review
Looks like the cause is focus/blur events are blocked by script blocker maybe due to loading or reflowing the page. Maybe, this fixes the random orange. https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=ec4095b36699
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Attachment #579612 - Flags: review?(bugs)
Attachment #579612 - Flags: review?(bugs) → review+
Whiteboard: [orange] → [orange][inbound]
Target Milestone: --- → mozilla11
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
I thought it was bad practice to add timers. They should only be added when they are really needed, no?
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #207) > I thought it was bad practice to add timers. They should only be added when > they are really needed, no? I think that they are necessary. The first timer in focus handler prevents nesting DOM events. The second timer in doTest() checks whether there are no delayed blur events.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Ah, I see. I'll post a patch.
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #217) > Ah, I see. I'll post a patch. Er, no I misunderstood the failure. I have no idea for now.
Assignee: masayuki → nobody
Whiteboard: [orange][inbound] → [orange]
Attached patch patch — — Splinter Review
All the stuff about timeouts and blocked events isn't related to what the test was first created to test, so this patch just removes the test, as what it is testing is already being checked by the main focus test. I added an extra check just to make sure.
Assignee: nobody → enndeakin
Attachment #579612 - Attachment is obsolete: true
Status: REOPENED → ASSIGNED
Attachment #620295 - Flags: feedback?(masayuki)
Comment on attachment 620295 [details] [diff] [review] patch I agree.
Attachment #620295 - Flags: feedback?(masayuki) → feedback+
Status: ASSIGNED → RESOLVED
Closed: 14 years ago13 years ago
Resolution: --- → FIXED
Target Milestone: mozilla11 → mozilla15
Flags: in-testsuite+
Comment on attachment 620295 [details] [diff] [review] patch [Approval Request Comment] If this is not a sec:{high,crit} bug, please state case for ESR consideration: test-only orange fix User impact if declined: Greater ESR tbpl orange noise Fix Landed on Version: trunk+aurora+beta Risk to taking this patch (and alternatives if risky): None, test-only. String or UUID changes made by this patch: None See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
Attachment #620295 - Flags: approval-mozilla-esr10?
Comment on attachment 620295 [details] [diff] [review] patch test only, approving for ESR.
Attachment #620295 - Flags: approval-mozilla-esr10? → approval-mozilla-esr10+
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: