Now we support [AllowShared] in WebIDL, we don't need to manually check shareness
and throw exception if API don't accept SharedArrayBuffer, the binding will handle
it.
Differential Revision: https://phabricator.services.mozilla.com/D60001
--HG--
extra : moz-landing-system : lando
nsIMutable is used only by DOM Blob/File. But Blobs are immutable by spec.
FileBlobImpl has a couple of lazy member values, but those are called when
the object is cloned in order to be sent to a different thread/process.
Differential Revision: https://phabricator.services.mozilla.com/D58946
--HG--
extra : moz-landing-system : lando
nsIMutable is used only by DOM Blob/File. But Blobs are immutable by spec.
FileBlobImpl has a couple of lazy member values, but those are called when
the object is cloned in order to be sent to a different thread/process.
Differential Revision: https://phabricator.services.mozilla.com/D58716
--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
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
Bug 1534012 added a test for postMessage during load and that revealed that mLoading flag isn't always updated
soon enough, so add BrowsingContext::IsLoading which checks also possible local loading status.
Depends on D54754
Differential Revision: https://phabricator.services.mozilla.com/D54836
--HG--
extra : moz-landing-system : lando
The patch moves DeprioritizedLoadRunner handling from top level inner window to top level browsing context.
Differential Revision: https://phabricator.services.mozilla.com/D54754
--HG--
extra : moz-landing-system : lando
The way this test works is, it loads a page, then it navigates to
another page and exits. The mochitest browser-chrome leak detector
will report a leak if the first page isn't freed by the end of the
test.
To make this Fission-compatible, I first changed the page we navigate
to to be same-origin. This means that we won't tear down the original
process immediately when we navigate, which will break the various
test harness stuff.
Secondly, I enable the dom.ipc.keepProcessesAlive.webIsolated
preference, which means that the content process won't be torn down
immediately. If this pref is not set, then the usual process reuse
ends up destroying the window before the test ends, whether or not it
leaks.
I verified that this test fails when the patch from bug 1336811 is
backed out, both with and without Fission.
Differential Revision: https://phabricator.services.mozilla.com/D51944
--HG--
extra : moz-landing-system : lando
Simon Giesecke
shindli
Edgar Chen
Andrea Marchesini
Mihai Alexandru Michis
Matt Woodrow
Narcis Beleuzu
Brindusan Cristian
Kris Maglione
Noemi Erli
Daniel Varga
Gabriele Svelto
Boris Zbarsky
Dorel Luca
Olli Pettay
Junior Hsu
Andrew McCreight
Dana Keeler