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)
Toolkit
Find Toolbar
Tracking
()
RESOLVED
FIXED
mozilla20
People
(Reporter: RyanVM, Assigned: Gavin)
References
Details
Attachments
(1 file)
2.73 KB,
patch
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•12 years ago
|
||
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?
Comment 2•12 years ago
|
||
(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.
Updated•12 years ago
|
Severity: critical → blocker
Updated•12 years ago
|
tracking-firefox19:
--- → ?
Comment 3•12 years ago
|
||
Email to release-mgmt@mozilla.com works best in these situations, especially when over the holidays.
Comment 4•12 years ago
|
||
Gavin's agreed to take a look. Thanks Gavin :)
Assignee: nobody → gavin.sharp
Assignee | ||
Comment 5•12 years ago
|
||
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?
Assignee | ||
Comment 6•12 years ago
|
||
I disabled this test temporarily to reopen the tree while I debug further: https://hg.mozilla.org/releases/mozilla-aurora/rev/dbd0ccb6cdbd
Assignee | ||
Comment 7•12 years ago
|
||
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.
Comment 8•12 years ago
|
||
(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.
Assignee | ||
Comment 9•12 years ago
|
||
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...
Assignee | ||
Comment 10•11 years ago
|
||
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.
Assignee | ||
Comment 11•11 years ago
|
||
This is what I pushed.
Assignee | ||
Comment 12•11 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/c5c2d204f056
Assignee | ||
Comment 13•11 years ago
|
||
Looks like this will stick.
status-firefox19:
--- → fixed
Target Milestone: --- → mozilla20
Comment 14•11 years ago
|
||
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.
Description
•