Currently, when Mozmill is running tests that require the main testing browser window to draw chrome elements in the foreground, tests are unable to pass if the main testing browser window is in the background. Running mozmill tests on 1.9.1 currently put the window in the background, and thus some tests are failing. Whimboo made mention in IRC: <whimboo>: you can't bring it to front, sadly <whimboo>: it's something mozmill should do <whimboo>: when starting the browser <whimboo>: but looks like -foreground doens't really work with shiretoko

So we talked about that specific issue in our todays Mozmill project meeting. Given the fact that it is working fine for Namoroka and Minefield, we think it could be a core issue in Firefox itself. Benjamin, do you know if there was a fix which has been checked into trunk and 1.9.2, but not 1.9.1? This is a problem for our Mozmill test-runs because the browser automatically gets put behind all applications when it gets started. If you don't know, whom else I could ask? Thanks.

Not sure if I'm seeing the failure or not. Command line: mozmill -b ~/tmp/firefox/firefox -t mozmill-tests/firefox/testAwesomeBar --showall Minefield (nightly) results: INFO Passed: 20 INFO Failed: 0 INFO Skipped: 1 DEBUG | mozmill.endRunner | true 3.5.10 results: INFO Passed: 17 INFO Failed: 3 INFO Skipped: 1 DEBUG | mozmill.endRunner | true Is this what the failure here (or is it unrelated test failures)? As best I can tell, 3.5.10 opens in the foreground here. So, I'm not sure what I'm seeing. Ubuntu 10.04, Fluxbox window manager.

(In reply to comment #2) > 3.5.10 results: > INFO Passed: 17 > INFO Failed: 3 > INFO Skipped: 1 > DEBUG | mozmill.endRunner | true This is not the mozilla1.9.1 branch. Please use our mozmill-test repository and switch to the mozilla1.9.1 branch first. > Is this what the failure here (or is it unrelated test failures)? Looks like not related. > As best I can tell, 3.5.10 opens in the foreground here. So, I'm not sure what > I'm seeing. Ubuntu 10.04, Fluxbox window manager. hm, so this is Mac only then?

Which tests are failing because of this? any in particular?

(In reply to comment #4) > Which tests are failing because of this? any in particular? Recent test-run on OSX with Shiretoko opened in the foreground Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.12pre) Gecko/20100722 Shiretoko/3.5.12pre Some might be other fails but this is my output Test Failed : testSearchForAddons in /mozmill-tests/firefox/testAddons/testSearchAddons.js Test Failed : testAccessLocationBarHistory in /mozmill-tests/firefox/testAwesomeBar/testAccessLocationBar.js Test Failed : testCheckItemHighlight in /mozmill-tests/firefox/testAwesomeBar/testCheckItemHighlight.js Test Failed : testEscape in /mozmill-tests/firefox/testAwesomeBar/testEscapeAutocomplete.js Test Failed : testGoButtonOnTypeOnly in /mozmill-tests/firefox/testAwesomeBar/testGoButton.js Test Failed : testClickLocationBarAndGo in /mozmill-tests/firefox/testAwesomeBar/testGoButton.js Test Failed : testLocationBarSearches in /mozmill-tests/firefox/testAwesomeBar/testLocationBarSearches.js Test Failed : testSuggestHistoryAndBookmarks in /mozmill-tests/firefox/testAwesomeBar/testSuggestHistoryBookmarks.js Test Failed : testStarInAutocomplete in /mozmill-tests/firefox/testAwesomeBar/testSuggestHistoryBookmarks.js Test Failed : testFindInPage in /mozmill-tests/firefox/testFindInPage/testFindInPage.js Test Failed : testFormCompletion in /mozmill-tests/firefox/testFormManager/testBasicFormCompletion.js Test Failed : testSaveFormInformation in /mozmill-tests/firefox/testFormManager/testClearFormHistory.js Test Failed : testToggleFormManager in /mozmill-tests/firefox/testFormManager/testDisableFormManager.js Test Failed : testGoogleSuggestedTerms in /mozmill-tests/firefox/testGeneral/testGoogleSuggestions.js Test Failed : testPasswordNotificationBar in /mozmill-tests/firefox/testPasswordManager/testPasswordNotSaved.js Test Failed : testSavePassword in /mozmill-tests/firefox/testPasswordManager/testPasswordSavedAndDeleted.js Test Failed : testAddMozSearchPlugin in /mozmill-tests/firefox/testSearch/testAddMozSearchProvider.js Passed 200 :: Failed 17 :: Skipped 0

Or I should rather, it didn't open in the foreground.

hmm, I did find this in my error console, but not from using command line mozmill: Error: Warning: unrecognized command line flag -foreground Source File: file:///Applications/Firefox.app/Contents/MacOS/components/nsBrowserContentHandler.js Line: 708

See also bug 369147 for this error. It shouldn't be the problem here.

On the latest 1.9.1 (20100729) I can't reproduce this. My results are: INFO Passed: 181 INFO Failed: 38 INFO Skipped: 0 It fails some tests, but it looks like it's in the foreground. Also get a bunch of failures on 3.6: INFO Passed: 190 INFO Failed: 29 INFO Skipped: 0

on 10.6.4

Tried on another Mac box, can't reproduce, closing.

This is not fixed. See my screencast: http://screencast.com/t/MmUzY2Ux. Recorded with the latest version of Shiretoko and the developer version of Mozmill.

(In reply to comment #11) > Tried on another Mac box, can't reproduce, closing. What about Linux (Ubuntu) 10.04 or earlier? On every test run of mine on a Shiretoko nightly, the primary browser window will open in the background. I filed this as Linux because that's the only OS I was able to reproduce this.

(In reply to comment #13) > (In reply to comment #11) > > Tried on another Mac box, can't reproduce, closing. > > What about Linux (Ubuntu) 10.04 or earlier? > > On every test run of mine on a Shiretoko nightly, the primary browser window > will open in the background. I filed this as Linux because that's the only OS I > was able to reproduce this. I was unable to reproduce this on Ubuntu 10.04. I'll try again with latest Shiretoko nightly just to test again, but have had no luck so far. I can't guess what the difference is. If this is a systems setting issue, it would be good to know what the deal was and isolate that as much as possible. May/may not be possible.

Heather can not repro this on her mac, jhammel can't repo it on his linux. Henrik and I can repro on the mac but as I said Heather can't. I think this is due to some deeper OS integration issue and is not a mozmill bug. There's nothing we can do here. Heather and I were running the same OS, the same version of shiretoko, and the same version of mozmill & friends. My money is on --no-remote or default starting firefox with profiles or some sort of setting like that which is causing this odd behavior. Other versions on my mac behave properly, but every version I've tested of shiretoko (from 3.5.1 to 3.5.5 and 3.5.11 and nightly) do not work. I don't see anything I can do in mozmill to fix it, and though trying a number of things, nothing seemed to help. I think we're going to have to let this one go for 1.4.2. And we'll try to figure out what the system setting is after 1.4.2 (and therefore minus this bug, or close it INVALID as it is not a bug in mozmill).

(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #11) > > > Tried on another Mac box, can't reproduce, closing. > > > > What about Linux (Ubuntu) 10.04 or earlier? > > > > On every test run of mine on a Shiretoko nightly, the primary browser window > > will open in the background. I filed this as Linux because that's the only OS I > > was able to reproduce this. > > I was unable to reproduce this on Ubuntu 10.04. I'll try again with latest > Shiretoko nightly just to test again, but have had no luck so far. I can't > guess what the difference is. > > If this is a systems setting issue, it would be good to know what the deal was > and isolate that as much as possible. May/may not be possible. Yeah, it worksforme here. Using fluxbox window manager, if it matters. A few points: 1. While IIRC there is a firefox bug on this, this is also window manager specific behaviour and could be a bug there 2. As of this month, 3.5 will be unsupported anyway, so probably not worth putting too much time into this

(In reply to comment #16) > 2. As of this month, 3.5 will be unsupported anyway, so probably not worth > putting too much time into this Who said this? I haven't heard anything that we drop support for 3.5. AFAIK there are no plans for in the next couple of months.

(In reply to comment #17) > (In reply to comment #16) > > 2. As of this month, 3.5 will be unsupported anyway, so probably not worth > > putting too much time into this > > Who said this? I haven't heard anything that we drop support for 3.5. AFAIK > there are no plans for in the next couple of months. Just going by what our website says: http://www.mozilla.com/en-US/firefox/all-older.html """ Firefox 3.5.x will be maintained with security and stability updates until August 2010. """ Maybe I misinterpreted? I certainly don't know such things

That should probably be updated. :) Clint, have you tried a new user on your os x box yet? Does it solve the problem on your box?

My suspection is that this only happens if multiple screens are connected to a computer. All information we have collected points into that direction.

(In reply to comment #20) > My suspection is that this only happens if multiple screens are connected to a > computer. All information we have collected points into that direction. Confirmed!

What closure do we want on this?

Great to hear that! What to do? At least nothing for 1.4.2. It really looks like an old Firefox bug which has been fixed >1.9.1. No-one will care about Firefox 3.5.x. We should probably close this bug as WONTFIX and live with it until we stop support for 3.5. Clint, it's your turn...

Yep, I agree, and I finagled stuff on my mac yesterday afternoon (this is what I was doing when I was off IRC for so long) to attempt this with a new user and with a new user on my mac and no external screen attached, things worked with no problem. --> WONTFIX