1093941 - e10s - fix browser_url* tests to run under e10s

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect)

Description

[:Gijs (out for now; he/him)]

[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.

Comment 1

[Chris Peterson [:cpeterson]]

e10s test bugs block e10s, but not a particular milestone.

Comment 2

[Tim Taubert [:ttaubert] (inactive)]

(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.

Comment 3

[Mark Hammond [:markh] [:mhammond]]

Attachment: 0001-Bug-1093941-enabled-remaining-urlbar-tests-with-e10s.patch

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

Comment 4

[Tim Taubert [:ttaubert] (inactive)]

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 ?

Comment 5

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/16911df6b875

Comment 6

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/16911df6b875