[SeaMonkey] mochitest-browser-chrome: browser_bug462289.js random orange on Linux

RESOLVED FIXED in seamonkey2.0b1

Status

RESOLVED FIXED
10 years ago
6 years ago

People

(Reporter: kairo, Assigned: kairo)

Tracking

(Blocks: 1 bug, {intermittent-failure})

Trunk
seamonkey2.0b1
x86
Linux
intermittent-failure
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [cc-orange])

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

10 years ago
Sometimes, the test that tries navigating to the tab bar with the tab key in SeaMonkey's browser_bug462289.js fails on the Linux box. I have seen something like this on my machine when porting those tests to SeaMonkey. Focusing the inputField instead of the urlbar element helped in my tests there, but it looks like the Linux unittest VM still runs into such a problem randomly.
(Assignee)

Comment 1

10 years ago
Created attachment 372287 [details] [diff] [review]
if the urlbar is still focused, issue another VK_TAB

This patch re-introduces a workaround I had in place in a previous version of the patch to port the test, see bug 484188 comment #10 - if we still are on the urlbar, issue another VK_TAB. 
I'm not sure why we run into this only randomly and only on Linux, but I'd like to try this workaround as it doesn't change that the test is still checking for what it should, i.e. the tabbar being reachable with tab key navigation.
Assignee: nobody → kairo
Status: NEW → ASSIGNED
Attachment #372287 - Flags: review?(neil)

Comment 2

10 years ago
Comment on attachment 372287 [details] [diff] [review]
if the urlbar is still focused, issue another VK_TAB

>   document.getElementById("urlbar").inputField.focus();
>   EventUtils.synthesizeKey("VK_TAB", { });
> 
>+  // sometimes we end up still having focused the HTMLInputElement in the urlbar
If you're sure that we're still focusing the HTMLInputElement, then surely you should test for
document.activeElement == document.getElementById("urlbar").inputField
Also would it be possible to add a todo() to say "expected focus to move out of urlbar" (but only if it did not, of course, to avoid false negatives)?
(Assignee)

Comment 3

10 years ago
(In reply to comment #2)
> If you're sure that we're still focusing the HTMLInputElement,

I'm not sure about anything, I just *suspect* that this case is similar to what I saw locally sometimes, but if it's better to stall for a few weeks and have intermittent orange than to try fixing it fast, so be it. It's not like anyone would really care about orange or red SeaMonkey test boxes.
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1240870850.1240876058.28924.gz
Linux comm-central unit test on 2009/04/27 15:20:50
Summary: [SeaMonkey] browser_bug462289.js random orange on Linux → [SeaMonkey] mochitest-browser-chrome: browser_bug462289.js random orange on Linux
Whiteboard: [orange]
(Assignee)

Comment 5

9 years ago
Created attachment 374917 [details] [diff] [review]
v2: give focus the chance to settleAdditional diagnostic
[Backout: Bug 491624 comment 50]

Actually, I found out I still can reproduce this failure on my debug build, and it seems we are just not synchronously setting focus, so sometimes we happen to be too fast issuing the VK_TAB when focus hasn't actually settled. When using a setTimeout() in between, we give other things than our test JS the chance to run and that is enough to make the focus settle and be at the right element.
Attachment #372287 - Attachment is obsolete: true
Attachment #374917 - Flags: review?(neil)
Attachment #372287 - Flags: review?(neil)

Comment 6

9 years ago
Comment on attachment 374917 [details] [diff] [review]
v2: give focus the chance to settleAdditional diagnostic
[Backout: Bug 491624 comment 50]

It won't be the first setTimeout ;-)

[Aren't we supposed to replace setTimeout with executeSoon at some point?]
Attachment #374917 - Flags: review?(neil) → review+
(Assignee)

Comment 7

9 years ago
Pushed as http://hg.mozilla.org/comm-central/rev/f95a082f9424
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.0b1
Depends on: 491624
Attachment #374917 - Attachment description: v2: give focus the chance to settle → v2: give focus the chance to settleAdditional diagnostic [Backout: Bug 491624 comment 50]
Keywords: intermittent-failure
Whiteboard: [orange]

Updated

6 years ago
Whiteboard: [cc-orange]
You need to log in before you can comment on or make changes to this bug.