Closed Bug 814793 Opened 12 years ago Closed 11 years ago

Permanent browser_bug567306.js orange since packaging update landed on Aurora

Categories

(Toolkit :: Find Toolbar, defect)

defect
Not set
blocker

Tracking

()

RESOLVED FIXED
mozilla20
Tracking Status
firefox19 + fixed

People

(Reporter: RyanVM, Assigned: Gavin)

References

Details

Attachments

(1 file)

No clue why, but browser_bug567306.js has been permaorange on all platforms since bug 814232 landed on Aurora today. Clobbering didn't help. I'm at a loss.

https://tbpl.mozilla.org/php/getParsedLog.php?id=17307113&tree=Mozilla-Aurora

Rev3 Fedora 12 mozilla-aurora pgo test mochitest-browser-chrome on 2012-11-23 09:39:21 PST for push 93d820463a5e
slave: talos-r3-fed-075

TEST-START | chrome://mochitests/content/browser/browser/base/content/test/browser_bug567306.js
TEST-PASS | chrome://mochitests/content/browser/browser/base/content/test/browser_bug567306.js | Load listener called
TEST-INFO | chrome://mochitests/content/browser/browser/base/content/test/browser_bug567306.js | Console message: [JavaScript Error: "The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol." {file: "data:text/html,<h1%20id='h1'>Select%20Me</h1>" line: 0}]
TEST-PASS | chrome://mochitests/content/browser/browser/base/content/test/browser_bug567306.js | pageshow listener called
TEST-INFO | chrome://mochitests/content/browser/browser/base/content/test/browser_bug567306.js | must wait for focus
TEST-PASS | chrome://mochitests/content/browser/browser/base/content/test/browser_bug567306.js | find bar is not yet initialized
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_bug567306.js | Findbar is initialized with selection - Got , expected Select Me
Stack trace:
    JS frame :: chrome://mochikit/content/browser-test.js :: test_is :: line 474
    JS frame :: chrome://mochitests/content/browser/browser/base/content/test/browser_bug567306.js :: onFocus :: line 43
    native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0

INFO TEST-END | chrome://mochitests/content/browser/browser/base/content/test/browser_bug567306.js | finished in 886ms
Blocks: 814232
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.
Severity: critical → blocker
Email to release-mgmt@mozilla.com works best in these situations, especially when over the holidays.
Gavin's agreed to take a look. Thanks Gavin :)
Assignee: nobody → gavin.sharp
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 gavin@gavinsharp.com 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.
Attached patch fix the testSplinter Review
This is what I pushed.
Looks like this will stick.
Target Milestone: --- → mozilla20
https://hg.mozilla.org/mozilla-central/rev/209a63d0a38f
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.