When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
--HG--
extra : moz-landing-system : lando
This API is no longer possible to implement, as it will always try to set the
OriginAttributes on a content BrowsingContext after it has been attached, and JS
can never observe a detached BrowsingContext.
Users of this API are instead changed to perform assertions that
originAttributes have already been set correctly.
Differential Revision: https://phabricator.services.mozilla.com/D67046
--HG--
extra : moz-landing-system : lando
This effectively also undoes the change introduced in 3166149f37f1 (bug 1615302),
and makes it so that instead of ignoring the userTyped values, we clear them
out in the parent when doing a process flip before sending them down to
the new child process.
Differential Revision: https://phabricator.services.mozilla.com/D69862
--HG--
extra : moz-landing-system : lando
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
--HG--
extra : moz-landing-system : lando
This API is no longer possible to implement, as it will always try to set the
OriginAttributes on a content BrowsingContext after it has been attached, and JS
can never observe a detached BrowsingContext.
Users of this API are instead changed to perform assertions that
originAttributes have already been set correctly.
Differential Revision: https://phabricator.services.mozilla.com/D67046
--HG--
extra : moz-landing-system : lando
* Create new logger.
* Use logger for process switch logging.
* Remove "[process-switch]: " string from log messages, it is redundant.
This may eventually move to a whole new module if/when process switching
moves there.
Differential Revision: https://phabricator.services.mozilla.com/D65440
--HG--
extra : moz-landing-system : lando
* Create new logger.
* Use logger for process switch logging.
* Remove "[process-switch]: " string from log messages, it is redundant.
This may eventually move to a whole new module if/when process switching
moves there.
Differential Revision: https://phabricator.services.mozilla.com/D65440
--HG--
extra : moz-landing-system : lando
This new attribute on nsILoadInfo allows retrieving the BrowsingContext and
BrowsingContextId for the BC of the document to be loaded by an nsILoadInfo.
Differential Revision: https://phabricator.services.mozilla.com/D63127
--HG--
extra : moz-landing-system : lando
This doesn't block the STATE_START notification from the new process, as we currently have a second start notification (when DocumentChannel redirects to the real channel), so this is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D56818
--HG--
extra : moz-landing-system : lando
With DocumentChannel, the 'URI' of the channel that we proxy for RemoteWebProgress doesn't have the resolved URI, and reports the about: version instead.
All about: URIs are local these days, so we can just check for that scheme directly, and simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D54251
--HG--
extra : moz-landing-system : lando
With DocumentChannel, the 'URI' of the channel that we proxy for RemoteWebProgress doesn't have the resolved URI, and reports the about: version instead.
All about: URIs are local these days, so we can just check for that scheme directly, and simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D54251
--HG--
extra : moz-landing-system : lando
