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

Status: RESOLVED FIXED

(SeaMonkey :: Tabbed Browser, defect)

Description

[Robert Kaiser]

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.

Comment 1

[Robert Kaiser]

Attachment: 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.

Comment 2

[[e-mail]]

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)?

Comment 3

[Robert Kaiser]

(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.

Comment 4

[Serge Gautherie (:sgautherie)]

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1240870850.1240876058.28924.gz
Linux comm-central unit test on 2009/04/27 15:20:50

Comment 5

[Robert Kaiser]

Attachment: 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.

Comment 6

[[e-mail]]

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?]

Comment 7

[Robert Kaiser]

Pushed as http://hg.mozilla.org/comm-central/rev/f95a082f9424