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
The patch ensures we don't pass a nsIWebNavigation load flag to
nsIDocShell.defaultLoadFlags which is supposed to get nsLoadFlags (nsIRequest).
Differential Revision: https://phabricator.services.mozilla.com/D61168
--HG--
extra : moz-landing-system : lando
I tested this by using delay(1) instead of delay(100), which reliably gives me
the "Is on an error page initially" failure without these changes and reliably
passs with them.
Differential Revision: https://phabricator.services.mozilla.com//D60345
--HG--
extra : histedit_source : e1c31b6183b569d7474af0de09292cc51635af5d
Some notes about the changes:
Both test_bug384014.html and test_bug123696.html were testing reloading of
javascript: URI. The expected result of the iframes after reloading would
become about:blank. I deleted both file and instead wrote with
web-platform-test to cover reloading of javascript: URI since wpt is more
preferable.
storage-cache-error.html was utilizing javascript: URI to test bug 1262766.
javascript: URI would cause CacheStorage::Keys to throw a dom security
exception because the URI's principal (which did not match the principal of the
document in this case!) was a nullpricipal. With my patches the iframe's URL
would no longer be the javascript: URI, so it's no longer applicable for the
test case. Instead we can test what bug 1262766 was originally about - that
CacheStorage::Keys would throw a dom security exception if it's in a private
browsing window.
Differential Revision: https://phabricator.services.mozilla.com/D59465
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
Some of these were obvious typos. Others probably reflect once-correct components
that have been combined, split, or otherwise obsoleted; for these I've tried to
use the component associated with the bugs for recent changes to the affected files.
Differential Revision: https://phabricator.services.mozilla.com/D55756
--HG--
extra : moz-landing-system : lando
We normally get HttpChannelParent::OnStartRequest directly from nsHttpChannel::OnStartRequest, where we disable content conversion and ask the child to do it instead.
When we install a multipart converter, we defer calling HttpChannelParent::OnStartRequest until we've decoded parts, at which point content conversion is already applied to the stream.
This detects that case, and stops the child trying to do it a second time (which fails, and breaks the content).
Differential Revision: https://phabricator.services.mozilla.com/D55222
--HG--
extra : moz-landing-system : lando
This ensures that we wait for the desired URL in the browserLoaded call, rather
than resolving the first-loaded one.
This also renames the file to make it more indicative of what it actually tests.
Differential Revision: https://phabricator.services.mozilla.com/D55045
--HG--
extra : moz-landing-system : lando
Neil Deakin
Peter Van der Beken
Ed Lee
Boris Zbarsky
Mark Banner
Anny Gakhokidze
Kris Maglione
Arthur Iakab
Noemi Erli
Matt Woodrow
Olli Pettay
Andreea Pavel
egao
Valentin Gosu
Samael Wang
Johann Hofmann
Emma Malysz
Henri Sivonen
Oana Pop Rus
shindli
Daniel Varga
Geoff Brown
Kashav Madan