The problem with this test was that it was actually relying on the old
broken behaviour where the initial browser of the new window it opens
would be flipped from remote back to non-remote before loading its
contents and flipping remote again. Because it now starts remote
(and stays there instead of doing all of the extra work), the
test was more likely to fall into the trap that I described in
https://groups.google.com/forum/#!searchin/mozilla.dev.platform/1261842%7Csort:relevance/mozilla.dev.platform/gthFqog3J-M/Ypx-SNhEQgAJ
where the promiseBrowserLoaded was firing for the wrong page
load, which meant that the cookie hadn't had a chance to be
set yet.
I've converted the test to use the properly instrumented
BrowserTestUtils functions which wait for the window to be
properly ready, and it appears to pass on try with multiple
retriggers.
MozReview-Commit-ID: BtQRx7og52A
userTypedClear was used for two cases:
1) to keep track of whether we were in the middle of a loadURI call. This use is replaced by inLoadURI, which is
more sane when using e10s (though it's hard to be precise there because we're sending all web navigation calls to
the content process and this introduces a degree of asynchronousness that we just have to live with...).
2) to keep track of whether we were between a network start and a corresponding network stop, and whether the user
typed since the load properly started. This is now tracked on a small object on the browser binding, which has
appropriately named method so we're not just incrementing some magic number but actually understand what
we're saying, and so the information we get out (did the user type since this load started or not?) makes sense.
Note that we're keeping userTypedClear in session store information in order to remain backwards compatible.
It becomes a simple boolean-stored-as-int (1 or 0) that indicates whether we quit/crashed/stopped while a load
was pending, or not.
MozReview-Commit-ID: 5NbmVueocC7
userTypedClear was used for two cases:
1) to keep track of whether we were in the middle of a loadURI call. This use is replaced by inLoadURI, which is
more sane when using e10s (though it's hard to be precise there because we're sending all web navigation calls to
the content process and this introduces a degree of asynchronousness that we just have to live with...).
2) to keep track of whether we were between a network start and a corresponding network stop, and whether the user
typed since the load properly started. This is now tracked on a small object on the browser binding, which has
appropriately named method so we're not just incrementing some magic number but actually understand what
we're saying, and so the information we get out (did the user type since this load started or not?) makes sense.
Note that we're keeping userTypedClear in session store information in order to remain backwards compatible.
It becomes a simple boolean-stored-as-int (1 or 0) that indicates whether we quit/crashed/stopped while a load
was pending, or not.
MozReview-Commit-ID: 5NbmVueocC7
