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
This adds tests for issues brought up in bug 231393, bug 264610, bug 302575 and bug 1129564,
all of which fed into the current implementation of userTypedClear/userTypedValue. I intend
to move us away from userTypedClear, but I'm keen not to regress any of these issues, so
I'm adding automated tests to ensure that doesn't happen.
MozReview-Commit-ID: 1up2MIXzkzG
This helps us keep track of what windows we've chosen to forget, and helps
us avoid the problem of accidentally saving a window we've chosen to forget.
They'll always resolve, but might receive a negative success state
and a message. We're doing this so that we can maintain a Set of
in-flight flushes that we can call Promise.all on (which will
fast-fail if any Promise rejects, or will just never resolve if
one or more of the Promises never resolve).
We were using tagName before, which is fine for the dynamically created browsers
in new tabs, but not fine for the initial browser tab, which has a tagName of
"xul:browser" instead of "browser". Using localName makes sure that we don't
get the XML namespace included with the node name. We check the XUL namespace
separately be checking the namespaceURI.
We were using tagName before, which is fine for the dynamically created browsers
in new tabs, but not fine for the initial browser tab, which has a tagName of
"xul:browser" instead of "browser". Using localName makes sure that we don't
get the XML namespace included with the node name. We check the XUL namespace
separately be checking the namespaceURI.
We were using tagName before, which is fine for the dynamically created browsers
in new tabs, but not fine for the initial browser tab, which has a tagName of
"xul:browser" instead of "browser". Using localName makes sure that we don't
get the XML namespace included with the node name. We check the XUL namespace
separately be checking the namespaceURI.
