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
With this change two new attention states are introduced, "severe" and "warning",
along with the previous "success" and "no attention" states. "No attention" is
still a falsy value in order to mitigate any add-on compatibility issues.
"severe" and "warning states" now display an icon badge to the downloads button
(or the hamburger button if the downloads button is tucked away).
MozReview-Commit-ID: 3gc9Ji7zCXY
Adds a new IPC message to the PBrowser protocol exposing
the number of tabs in the current window to the content
process. This allows the content process to reject window.resize*
calls in cases where there is more than one tab in the
window.
If a <browser> is included within a chrome document, then this._state
will refer to the security state for the <browser> and not the top level
document. In this case, don't upgrade the security state in the UI
with the secure state of the embedded <browser>.
Most of this is fixing functions that in some cases return a value but then
can also run to completion without returning anything. ESLint 2 catches this
where previous versions didn't. Unless there was an obvious other choice I just
made these functions return undefined at the end which is effectively what
already happens.
MozReview-Commit-ID: DEskVIjiKDM
This is in order to optimize the critical path (the presenting of content to the user).
If we don't wait until the content has been presented for the tab switch, then we run
the risk of causing the content to send sync IPC messages for IME up to the parent,
which slows down the rendering of the content.
MozReview-Commit-ID: B0anKV8YVUz
When the application is asked to quit, all windows are checked to see if
they can close (which will spawn the permit unload dialogs). Once the
user grants the quit via the permit unload dialogs, nsIAppStartup
returns true for the shuttingDown attribute, and we know that all
windows allowed the shutdown to occur. This means that we don't
have to show the permitUnload dialogs again when SessionStore
attempts to close the windows when it does its final async window
flush during the quit-application-granted observer topic.
MozReview-Commit-ID: DOy8ljngnTd
