Closed Bug 814793 Opened 7 years ago Closed 7 years ago
_bug567306 .js orange since packaging update landed on Aurora
As much as I love leaving Aurora closed for 3+ days in a row, I'm wondering at what point we bite the bullet and back bug 814232 out. Alex, can you poke someone to look into this otherwise?
(In reply to Ryan VanderMeulen from comment #1) > As much as I love leaving Aurora closed for 3+ days in a row, I'm wondering > at what point we bite the bullet and back bug 814232 out. Alex, can you poke > someone to look into this otherwise? I don't feel backing out bug 814232 is the right solution; aurora needs to be branded aurora. The lack of activity is most likely due to people catching up on bugmail after the long weekend and I'm hopeful within a few hours this will be resolved.
Email to email@example.com works best in these situations, especially when over the holidays.
Gavin's agreed to take a look. Thanks Gavin :)
This is a mysterious one. I could initially reproduce locally (built aurora with both sets of branding - passed with "nightly", failed with "aurora"). Chased that around a little bit, but just now tested Nightly from trunk, and I get the same failure there too. Rebuilt from trunk, no failure. So I think the test is just flaky, but something very clearly had a effect to make this permaorange now when it wasn't before. Random timing?
I disabled this test temporarily to reopen the tree while I debug further: https://hg.mozilla.org/releases/mozilla-aurora/rev/dbd0ccb6cdbd
So the findbar.xml code is seeing different "focused windows" here when I reproduce the issue locally: http://hg.mozilla.org/mozilla-central/annotate/1489b6c2d1d2/toolkit/content/widgets/findbar.xml#l1696 When it fails, the focused window is a browser.xul window - when it passes, it's the test's content window. Why the window focus behavior would be different based on branding is still a mystery, though.
(In reply to :Gavin Sharp (use firstname.lastname@example.org for email) from comment #6) > I disabled this test temporarily to reopen the tree while I debug further: > https://hg.mozilla.org/releases/mozilla-aurora/rev/dbd0ccb6cdbd Thanks for following up Gavin! Glad to see the tree's open again.
So part of the test's bustedness is that it tries to pass testWindow.contentWindow as the window to focus, but that is undefined, so waitForFocus falls back to using the current chrome window. Switching that to testWindow.gBrowser.contentWindow fixes the failure, but I still have no idea why this brokenness is only exposed with Aurora branding. I could maybe see it being some Mac-specific focus behavior based on bundle ID, but this showed up on tinderbox pretty consistently across platforms...
I pushed https://hg.mozilla.org/integration/mozilla-inbound/rev/209a63d0a38f to inbound, because the patch for bug 802026 caused this test to start failing there. Since the test is obviously busted, I suspect we just got very lucky that it's otherwise been passing on central for a while, and any number of "random" changes can make us lose this race and fail. If this works on central I'll try the same on Aurora.
This is what I pushed.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.