If the tab was resumed before, it could start playing any autoplay media without user's
permission after session restore.
MozReview-Commit-ID: C3DHIIsLtJA
--HG--
extra : rebase_source : 9517525aa242bff3150a902070544cf64c5ba6c1
The browser.contentPrincpal will report a null prinicpal instead of the actual
content principal if the tab is not loaded. So the SessionStore will collect a
wrong principal for the 'iconLoadingPrincipal', and it will use this wrong
principal to load favicon when session restoring.
To fix this problem, this patch makes the TabState.jsm to collect
'iconLoadingPrincipal' from browser.mIconLoadingPrincipal which will be the
correct principal for loading favicon.
MozReview-Commit-ID: AYUbHFKaG8v
--HG--
extra : rebase_source : 3e2333f18c221d415bd0e26bc416a841344cef2c
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
--HG--
extra : rebase_source : 55cd9f3513c0a985580957a5157d47853a8822bf
extra : source : 386b9c750bd2ed458112acd29eb72e4e1371af9d
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
--HG--
extra : rebase_source : f87199c77094c24c132e6c88f751a5b5d5aa62f9
In a following patch, all DevTools moz.build files will use DevToolsModules to
install JS modules at a path that corresponds directly to their source tree
location. Here we rewrite all require and import calls to match the new
location that these files are installed to.
--HG--
extra : commitid : F2ItGm8ptRz
extra : rebase_source : b082fe4bf77e22e297e303fc601165ceff1c4cbc
