See bug 823989 comment 30 for the analysis also see the attached IRC log of the conversation.

Based on the lack of testing in bug 823989 we are at risk of shipping FF20 without the testing that has been disabled and we need to get it back. Neil - are you the right person to take this?

:ehsan I am trying to find where TP actually does that focusing, but failing.

See my analysis in bug 823989 comment 30. I suggest reading that bug more closely before you delve deeper into this.

Can we just drop that call to BrowserToolboxCustomizeDone instead?

(In reply to Gregg Lind (User Research - Test Pilot) from comment #4) > Can we just drop that call to BrowserToolboxCustomizeDone instead? No I think you're supposed to call that if you customize the toolbar... But Gavin/Dao can correct me if I'm wrong here.

Ehsan: Do you still have the list of things that happen when focus logging is turned on? Perhaps there's an earlier event that we could use to assign mActiveWindow (on Linux only?) instead… (Did we talk about this before? This whole conversation seems really familiar for some reason…)

Does someone have a log with 'Focus', 'Widget' and 'WidgetFocus' prlogging enabled? If so, could they post it to this bug?

I don't have a focus log for this, and I don't think that I ever did. But reproducing this is _trivial_ on Linux, just update to the parent revision of my workaround landed in bug 823989, hack the Makefile to make testpilot build, and run the browser-chrome test suite on Linux. Happens on every single test run, no exception. I had no difficulty reproducing locally.

I have no Linux machine at present so I'd hoped someone would be able to generate log I could at.

(In reply to Neil Deakin from comment #9) > I have no Linux machine at present so I'd hoped someone would be able to > generate log I could at. Neil, I've got a Linux VM on my desktop computer that you could use whenever you want. Come bug me when you're in the office?

Neil, have you been able to reproduce this now?

No. I get a plugin-related test timing out when I made no changes, and I get the same when the preference change is reverted and thus BrowserToolbarCustomizeDone call is made. I verified that TestPilot is installed and that the call to that function is made, and is made before WindowRaised is called. The descriptions above and in the other bug suggest though that the timeout occur before any tests run, so maybe I am getting a different issue. After the plugin test times out, the remaining tests continue normally.

Given https://bugzilla.mozilla.org/show_bug.cgi?id=823989#c73 untracking for 20

Neil, any updates here?

No, I can't reproduce it.

Btw, I am fine with closing this at this point (as a "seriously, wtf, cantfix"). I think it's actually just fine for me to start trying to land TP2, which doesn't have any of these issues. ENN has been amazing at trying to solve this "the right way".

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.