Closed Bug 1093941 Opened 10 years ago Closed 9 years ago

e10s - fix browser_url* tests to run under e10s

Categories

(Firefox :: Address Bar, defect)

defect
Not set
normal
Points:
8

Tracking

()

RESOLVED FIXED
Firefox 40
Iteration:
40.3 - 11 May
Tracking Status
e10s + ---
firefox40 --- fixed

People

(Reporter: Gijs, Assigned: markh)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

[browser_urlbarAutoFillTrimURLs.js]

Waits indefinitely for onSearchComplete. Not sure why that isn't fired.

[browser_urlbarEnter.js]

The comment says this crashed on try. It might not anymore?

[browser_urlbarRevert.js]

Fails with: ESC reverted the location bar value - Got foobar, expected example.com

Presumably this has to do with synthesizeKey not working right? Maybe? It's a little odd though, because this is all parent process...

[browser_urlbarStop.js]
The test calls gBrowser.contentWindow.stop(), which doesn't work. I don't know why our shimming doesn't cover this; perhaps there are other ways of doing this that already work?

Otherwise, this will require a small bit of messaging. See e.g. http://mxr.mozilla.org/mozilla-central/source/browser/base/content/test/general/browser_save_video_frame.js#49 for an idea on how to do this.


Requesting tracking-e10s because I think esp. what with unifiedcomplete, we should make doubly sure that our location bar works correctly under e10s as well.
Flags: qe-verify-
Flags: in-testsuite+
Flags: firefox-backlog+
e10s test bugs block e10s, but not a particular milestone.
(In reply to :Gijs Kruitbosch from comment #0)
> [browser_urlbarStop.js]
> The test calls gBrowser.contentWindow.stop(), which doesn't work. I don't
> know why our shimming doesn't cover this; perhaps there are other ways of
> doing this that already work?

This single test will be fixed by bug 1100291. We'll have to rewrite it properly anyway and that will make it e10s compatible too.
Depends on: 1100291
There are only 2 tests that remain disabled for this bug. browser_urlbarAutoFillTrimURLs.js seems to work fine while browser_urlbarEnter.js needed a little love  - the first change should be obvious from the comment, while the second change is more subtle - waiting for the "load" event of gBrowser.selectedBrowser was actually waiting for the load of the *initial* tab (ie, .selectedBrowser hasn't been updated by the time that is called) - that load event never came due to the promiseTabLoaded meaning it already fired.

Try at https://treeherder.mozilla.org/#/jobs?repo=try&revision=56f41220a77d
Assignee: nobody → mhammond
Status: NEW → ASSIGNED
Attachment #8600792 - Flags: review?(ttaubert)
Comment on attachment 8600792 [details] [diff] [review]
0001-Bug-1093941-enabled-remaining-urlbar-tests-with-e10s.patch

Review of attachment 8600792 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/base/content/test/general/browser_urlbarEnter.js
@@ +26,5 @@
>    info("Alt+Return keypress");
>    let tab = gBrowser.selectedTab = gBrowser.addTab(START_VALUE);
> +  // due to bug 691608, we must wait for the load event, else isTabEmpty() will
> +  // return true on e10s for this tab, so it will be reused even with altKey.
> +  yield promiseTabLoaded(tab);

Nit: Could as well use BrowserTestUtils.browserLoaded().

@@ +32,5 @@
>    gURLBar.focus();
>    EventUtils.synthesizeKey("VK_RETURN", {altKey: true});
> +
> +  // wait for the new tab to appear.
> +  yield BrowserTestUtils.waitForEvent(document, "TabOpen");

Nit: s/document/gBrowser.tabContainer ?
Attachment #8600792 - Flags: review?(ttaubert) → review+
Iteration: --- → 40.3 - 11 May
https://hg.mozilla.org/mozilla-central/rev/16911df6b875
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 40
You need to log in before you can comment on or make changes to this bug.