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
I think I caught all the places in our tree that add event listeners for these
events on a non-Window (and hence depend on bubbling behavior), but I'm a
little worried about what happens if webextensions do bareword
addEventListener() for these events...
Differential Revision: https://phabricator.services.mozilla.com/D66798
--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 patch was generated with a script. It doesn't include all files:
- Files that use the preprocessor or fail to parse are skipped
- Files that are loaded as JSMs but don't use the .jsm extension are skipped (those will be renamed in Bug 1609269)
It was generated with the following command using d855222aa2/no-this-property-read.js:
```
hg revert --all &&
cp .gitignore .rgignore &&
rg --files-without-match -g '*.jsm' '^#endif|^#include|^#filter' | jscodeshift --stdin --transform ~/Code/jsm-rewrites/no-this-property-read.js --ignore-pattern ./mobile/android/modules/Sanitizer.jsm --ignore-pattern ./js/xpconnect/tests/unit/syntax_error.jsm &&
./mach eslint `hg st | rg '^M ' | sed 's/^M //'`
```
Differential Revision: https://phabricator.services.mozilla.com/D60187
--HG--
extra : moz-landing-system : lando
