691608 - e10s support for isTabEmpty

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[:Gavin Sharp [email: [e-mail]]]

With e10s enabled, isTabEmpty can't directly reach into the tab's content document to check its childNodes. It's not clear to me how this should work - its callers generally don't really want to have to wait for a message round trip, but having the child constantly notify the parent of the state of its DOM isn't feasible either.

Comment 1

[Felix Fung (:felix)]

>function isTabEmpty(aTab) {
>  let browser = aTab.linkedBrowser;
>  return browser.sessionHistory.count < 2 && 
>         browser.currentURI.spec == "about:blank" &&
>         !browser.contentDocument.body.hasChildNodes() &&
>         !aTab.hasAttribute("busy");
>}

How can there be childNodes if the currentURI is about:blank?

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Example:
var w = window.open();
w.document.body.appendChild(w.document.createTextNode("hi!"));


"w" now has about:blank loaded, but it isn't a "blank" tab.

Comment 3

[Matt Brubeck (:mbrubeck)]

It looks like the hasChildNodes check has been removed, and now the only part that doesn't work is "browser.contentWindow.opener".  It seems like it should be easy to cache this when the tab is first created.

Comment 4

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

browser_urlbarEnter.js is currently failing in e10s due to isTabEmpty() returning true when it should be false.  The URLBar uses isTabEmpty() to decide whether to treat Alt+Enter as a normal enter (ie, if the tab is empty it just reuses the current tab).

The url is about:blank while initially loading so isTabEmpty() returns true. While the test can work around this by waiting for the tab load event before simulating Alt+Enter, it seems wrong that isTabEmpty() may return true in this case.

Comment 5

[Jim Mathies [:jimm]]

implemented and the test is enabled.