A lot of JS WebProgressListeners only implement the callback methods that they
actually care about. This is a completely reasonable thing to do, and
reporting errors for those missing methods just adds unhelpful noise to test
results. We should just ignore those errors instead.
Differential Revision: https://phabricator.services.mozilla.com/D56451
--HG--
extra : moz-landing-system : lando
This is the last message that WebProgressChild was sending to the
RemoteWebProgress in the parent process, so we can remove the module entirely.
Differential Revision: https://phabricator.services.mozilla.com/D35091
--HG--
extra : moz-landing-system : lando
This is the last message that WebProgressChild was sending to the
RemoteWebProgress in the parent process, so we can remove the module entirely.
Differential Revision: https://phabricator.services.mozilla.com/D35091
--HG--
extra : moz-landing-system : lando
This is the last message that WebProgressChild was sending to the
RemoteWebProgress in the parent process, so we can remove the module entirely.
Differential Revision: https://phabricator.services.mozilla.com/D35091
--HG--
extra : moz-landing-system : lando
The `WebProgress#sendLoadCallResult` method only existed to send a empty async
message and was only called from the `WebNavigationChild`. Since
`WebNavigationChild` is in the process of being removed, it makes sense to
inline the replaced method into its call site.
Differential Revision: https://phabricator.services.mozilla.com/D34566
--HG--
extra : moz-landing-system : lando
The `WebProgress#sendLoadCallResult` method only existed to send a empty async
message and was only called from the `WebNavigationChild`. Since
`WebNavigationChild` is in the process of being removed, it makes sense to
inline the replaced method into its call site.
Differential Revision: https://phabricator.services.mozilla.com/D34566
--HG--
extra : moz-landing-system : lando
The `WebProgressChild` no longer sends a `matchedList` parameter in its JSON
messages to the `RemoteWebProgress`, so it will always be undefined and trigger
a `ReferenceError`.
Differential Revision: https://phabricator.services.mozilla.com/D33202
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
We do not need to handle onProgressChange64 notifications since the TabChild's
web progress events are filtered through an nsBrowserStatusFilter, which
truncates onProgresChange64 event values to 32-bit integers and then calls
onProgressChange.
Differential Revision: https://phabricator.services.mozilla.com/D25649
--HG--
extra : moz-landing-system : lando
Now that we have access to the RemoteWebProgress from the TabParent and can
construct RemoteWebProgress and RemoteWebProgressRequests in C++, we can
reconstruct the RemoteWebProgress and RemoteWebProgressRequest in the TabParent
instead of RemoteWebProgressManager. This improves the API for nsIBrowser and
RemoteWebProgressManager, removing the need for the
`callWebProgressContentBlockingEventListeners` method in both. It also means we
won't need to implement `callWebProgress*Listeners` for methods on nsIBrowser
and RemoteWebProgressManager for all other nsIWebProgress events.
Differential Revision: https://phabricator.services.mozilla.com/D24942
--HG--
extra : moz-landing-system : lando
The RemoteWebProgressManager is now implemented in terms of a
nsIWebProgressListener. This paves the way for reconstructing the
nsIWebProgress and nsIRequest passed to the event handlers in C++ instead of in
JS and will alllow for a cleaner overall design.
While here, I also cleaned up RemoteWebProgressManager to use the class
syntactic sugar.
Differential Revision: https://phabricator.services.mozilla.com/D24941
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
For simplicity, we do not support remote-to-non-remote or non-remote-to-remote
nsIWebProgressListener persistence.
Differential Revision: https://phabricator.services.mozilla.com/D7936
--HG--
extra : moz-landing-system : lando