Closed Bug 535903 Opened 10 years ago Closed 10 years ago

[SeaMonkey 2.1] mochitest-browser-chrome: "browser_focus_steal_from_chrome.js | Timed out"

Categories

(Core :: DOM: Core & HTML, defect, major)

defect
Not set
major

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- -

People

(Reporter: sgautherie, Assigned: iann_bugzilla)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file)

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a1pre) Gecko/20091218 SeaMonkey/2.1a1pre] (home, optim default) (W2Ksp4)
{
Console message: [JavaScript Error: "BrowserSearch is not defined" {file: "chrome://mochikit/content/browser/dom/tests/browser/browser_focus_steal_from_chrome.js" line: 133}]

Console message: [JavaScript Error: "BrowserSearch is not defined" {file: "chrome://mochikit/content/browser/dom/tests/browser/browser_focus_steal_from_chrome.js" line: 149}]

Timed out
}
Summary: [SeaMonkey 2.1] mochitest-browser-chrome: 2 "Console message: [JavaScript Error: "BrowserSearch is not defined" {file: "chrome://mochikit/content/browser/dom/tests/browser/browser_focus_steal_from_chrome.js" line: 1xx}]" → [SeaMonkey 2.1] mochitest-browser-chrome: "browser_focus_steal_from_chrome.js | Timed out"
SeaMonkey does not have a search bar.
See Also: → 534420
Why are the "browser" tests shared between different products??
I think these are actually DOM tests that just happen to use the browser for test purposes.

SeaMonkey specific browser tests are in [comm-central]/suite/browser/tests/
Firefox specific browser tests are in [mozilla-central]/browser/*/tests/
That's correct.  Things that are in dom/ are supposed to be testing universal DOM functionality.
And a "steal focus from chrome" test does sound like it should live in dom/
Then it would be good if the test would be done with some element that is at visible in both browsers running those tests or it should fail gracefully (possibly with a TODO) when the element to test with isn't found in the first place.
Linux and MacOSX too:
{
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1266802111.1266803198.17758.gz
Linux comm-central-trunk debug test mochitest-other on 2010/02/21 17:28:31

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1266802005.1266803746.19182.gz
OS X 10.5 comm-central-trunk debug test xpcshell on 2010/02/21 17:26:45
}
Severity: normal → major
OS: Windows 2000 → All
Hardware: x86 → All
Bug still there.
Masayuki, what's the plan to solve this?
Blocks: 125282
blocking2.0: --- → ?
No longer depends on: 125282
And this failure is causing at least the 4 next browser_Browser.js failures (because a tab is left open).
No longer blocks: CcMcBuildIssues
Component: Layout: Form Controls → DOM
QA Contact: layout.form-controls → general
Not blocking the release on this.
blocking2.0: ? → -
Switches to finding an element with an id urlbar making the test not dependent on code sitting in /browser (i.e. BrowserSearch).
Is test only but asking for a= anyway.
Assignee: nobody → iann_bugzilla
Status: NEW → ASSIGNED
Attachment #472196 - Flags: review?(bzbarsky)
Attachment #472196 - Flags: approval2.0?
Attachment #472196 - Flags: review?(bzbarsky) → review+
Comment on attachment 472196 [details] [diff] [review]
Switch to a more generic chrome element patch v0.1 [Checked in: comment 14]

As a test a=testing NPODB
Attachment #472196 - Flags: approval2.0?
Comment on attachment 472196 [details] [diff] [review]
Switch to a more generic chrome element patch v0.1 [Checked in: comment 14]

http://hg.mozilla.org/mozilla-central/rev/fe3a1059a92b
Attachment #472196 - Attachment description: Switch to a more generic chrome element patch v0.1 → Switch to a more generic chrome element patch v0.1 [Checked in: comment 14]
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.