IPC crashes if you try to send large messages. The message manager
already drops messages that are too big (and used to collect telemetry
for which messages were being dropped).
I think that some message manager messages have been ported over to JS
window actors and started crashing on beta, so let's just give the
same behavior for JS window actors as we do for the message manager.
Differential Revision: https://phabricator.services.mozilla.com/D57583
--HG--
extra : moz-landing-system : lando
When we open a new window from a content process, we create a nested event
loop to wait for it to be initialized by the parent. The problem with this is
that the OpenWindow code which calls the window provider expects the window to
be in-process and uninitialized, so that it can load its own initial URI into
it, and correctly fulfil the spec-codified contract of window.open(). If
another caller initiates a load in the new window during the nested event
loop, those invariants are broken, and any manner of undefined behavior can
occur.
This patch adds a new flag to the BrowsingContext, marking it as uninitialized
until the end of the nested event loop, and blocking any attempts to load a
new URI into it in the meantime.
Differential Revision: https://phabricator.services.mozilla.com/D57667
--HG--
extra : moz-landing-system : lando
This doesn't solve all problems with potential reentrancy during window.open
nested event loops, but it does improve the situation somewhat. Since any
window in the same BrowsingContextGroup can target any window in the same
group, we need to suspend all windows in the group, not just the root of the
new window's parent. We also need to make sure we suspend all in-process
windows, even if we have out-of-process frames somewhere in the parent chain.
This patch takes care of suspending timeouts and input event handling in all
of these cases. It doesn't block all potential paths for running code in the
suspended windows, though, so the next patch explicitly prevents the
problematic reentrancy.
Differential Revision: https://phabricator.services.mozilla.com/D57666
--HG--
extra : moz-landing-system : lando
This is fallout from landing Bug 1586370, we have Bug 1605134 already on file
as a followup, so we'll disable the test for now and fix as part of that bug.
Depends on D57829
Differential Revision: https://phabricator.services.mozilla.com/D57845
--HG--
extra : moz-landing-system : lando
In a follow-up commit a new `ComparePoints` method with cleaner
arguments and return value will be added.
Differential Revision: https://phabricator.services.mozilla.com/D55295
--HG--
extra : moz-landing-system : lando
There is no functional change with this commit. The default implementation for GetCanceled() is still to check if the status code is a failure.
However, it can be argued that as you had to call Cancel() on the nsIChannel, having to check the nsIHttpChannelInternal interface to determine if you had been canceled in the past was rather a non obvious path.
It makes more sense to check the nsIChannel interface to determine if it's been canceled already and this allows for finer granularity if needed in the future.
Differential Revision: https://phabricator.services.mozilla.com/D55268
--HG--
extra : moz-landing-system : lando
We do want to use it for nsContentUtils::CallOnAllRemoteChildren and
SubDocEnumFunc since `boolean` is quite confusing whether we still need to
enumerate further children or not, actually
nsContentUtils::CallOnAllRemoteChildren stops in case of `true`, whereas
SubDocEnumFunc stops on `false`
Differential Revision: https://phabricator.services.mozilla.com/D57435
--HG--
extra : moz-landing-system : lando
We are going to introduce a new function in Document in this commit series,
which enumerates all child documents regardless of whether it's in the same
process, in content processes or in out-of-process iframes. The function takes
std::functions, but I don't have any good ideas to convert lambda functions with
capturing variables to function pointer.
Differential Revision: https://phabricator.services.mozilla.com/D57434
--HG--
extra : moz-landing-system : lando
On GTK changing gtk-enable-animation in a process doesn't affect in different
processes for some reasons. So we take the same approach as what we did for
OSX[1] that is when SetPrefersReducedMotionOverrideForTest is called we set the
given value as a cache in the parent process and send a notification to system
as if the value changed thus the notification kicks PBroser.ThemeChanged to
update the cache in the content process, thus we can use the cache value on
querying the corresponding value in the content process.
[1] https://hg.mozilla.org/mozilla-central/rev/67a5acf7363d
Differential Revision: https://phabricator.services.mozilla.com/D57260
--HG--
extra : moz-landing-system : lando
We do want to use it for nsContentUtils::CallOnAllRemoteChildren and
SubDocEnumFunc since `boolean` is quite confusing whether we still need to
enumerate further children or not, actually
nsContentUtils::CallOnAllRemoteChildren stops in case of `true`, whereas
SubDocEnumFunc stops on `false`
Differential Revision: https://phabricator.services.mozilla.com/D57435
--HG--
extra : moz-landing-system : lando
We are going to introduce a new function in Document in this commit series,
which enumerates all child documents regardless of whether it's in the same
process, in content processes or in out-of-process iframes. The function takes
std::functions, but I don't have any good ideas to convert lambda functions with
capturing variables to function pointer.
Differential Revision: https://phabricator.services.mozilla.com/D57434
--HG--
extra : moz-landing-system : lando
On GTK changing gtk-enable-animation in a process doesn't affect in different
processes for some reasons. So we take the same approach as what we did for
OSX[1] that is when SetPrefersReducedMotionOverrideForTest is called we set the
given value as a cache in the parent process and send a notification to system
as if the value changed thus the notification kicks PBroser.ThemeChanged to
update the cache in the content process, thus we can use the cache value on
querying the corresponding value in the content process.
[1] https://hg.mozilla.org/mozilla-central/rev/67a5acf7363d
Differential Revision: https://phabricator.services.mozilla.com/D57260
--HG--
extra : moz-landing-system : lando
Granted origins cause a third-party tracker browsing context to not get
full first-party storage access after successfully calling the storage
access API or a heuristic granting ephemeral access.
For example, after https://tracker.example calls the storage access API
successfully in the third-party context, they embed
https://other-tracker.example, and that load fails because of ETP
restrictions. Here what happens is that https://other-tracker.example
is mistakenly considered the granted origin, and because such a
permission doesn't exist, access is denied.
Differential Revision: https://phabricator.services.mozilla.com/D57493
--HG--
extra : moz-landing-system : lando
We also need to adjust the scroll range we use. We do this by adding GetScrollRangeForUserInputEvents which just uses the range that GetAvailableScrollingDirectionsForUserInputEvents computed.
This should give two improvements:
1) CanScrollOn will not report that the user can scroll in an overflow hidden direction.
2) CanScrollOn will report that the user can scroll in an overflow hidden direction if the document is pinch zoomed in so that the user can scroll around the layout viewport.
Differential Revision: https://phabricator.services.mozilla.com/D56301
--HG--
extra : moz-landing-system : lando
Unfortunate, but this is an existing intermittent that is blocking bug 1586370
from landing.
Differential Revision: https://phabricator.services.mozilla.com/D57554
--HG--
extra : moz-landing-system : lando
Since we now run a fallback driver while an AudioCallbackDriver starts, this has
exposed a path where the double-append-during-iteration assertion fails.
It seems to happen at least when there's an audio->audio driver switch, and a
fallback driver was running in between.
The state for this assertion assumes it's reset when the AudioCallbackDriver
that's feeding it starts, but forgot to account for driver switches and
fallbacks, which could still cause silence to be pulled for the track.
Differential Revision: https://phabricator.services.mozilla.com/D57037
--HG--
extra : moz-landing-system : lando
This allows the graph to run in case starting the audio driver takes a long
time. We could also do this only for audio->audio driver switches as there is
not much point to keep the graph iterating if we are starting a new graph, or
switching to or from audio. That would however mean more paths, and implied,
harder-to-catch bugs.
Differential Revision: https://phabricator.services.mozilla.com/D56085
--HG--
extra : moz-landing-system : lando
Note that this will only switch to the fallback driver once, and never switch
back. This will improve in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D56083
--HG--
extra : moz-landing-system : lando
This makes it simpler to maintain state in the GraphDriver in more complex
cases, such as when an AudioCallbackDriver is backed by a fallback driver.
Differential Revision: https://phabricator.services.mozilla.com/D57553
--HG--
extra : moz-landing-system : lando
This lets us iterate more things than MediaTrackGraphImpl, e.g., audio drivers
(from the fallback driver) and unit test classes.
Differential Revision: https://phabricator.services.mozilla.com/D56082
--HG--
extra : moz-landing-system : lando
This will let us get rid of such GraphDriver dependencies on MediaTrackGraphImpl
as SignalMainThreadCleanup and SetCurrentDriver.
Differential Revision: https://phabricator.services.mozilla.com/D56076
--HG--
extra : moz-landing-system : lando
This removes a level of indirection where the graph had to call back into
AudioContext. It also removes a dependency on the graph from GraphDriver, where
it can now just resolve a MozPromiseHolder instead.
Differential Revision: https://phabricator.services.mozilla.com/D56075
--HG--
extra : moz-landing-system : lando
This is where TrackTicks is defined, which is what they convert to and from.
Differential Revision: https://phabricator.services.mozilla.com/D56073
--HG--
extra : moz-landing-system : lando
This removes some driver-graph interdependencies.
It also changes the logic of EnsureNextIteration() so that it no longer blindly
wakes the driver up, should it be sleeping. Instead it waits until the driver's
next iteration would have occurred anyway, as that seems more expected, and
closer to how an AudioClockDriver works.
Differential Revision: https://phabricator.services.mozilla.com/D56069
--HG--
extra : moz-landing-system : lando
This let's us remove GraphDriver's dependency on the graph's message queues.
Differential Revision: https://phabricator.services.mozilla.com/D56068
--HG--
extra : moz-landing-system : lando
I found this while running local tests. In particular
`./mach test dom/media/test/test_mediarecorder_record_addtracked_stream.html --headless --repeat 1`.
Differential Revision: https://phabricator.services.mozilla.com/D56066
--HG--
extra : moz-landing-system : lando
Add a document.addCertException function to about:certerror pages, and use it on the desktop certerror page.
Also, as the CallerIsTrusted* functions expect URLs like about:certerror, but GeckoView error pages are data URLs, and so need to be handled differently for these special error-page methods to be exposed on their documents.
Example usage of document.addCertException:
document.addCertException(
true|false /* true == temporary, false == permanent */
).then(
() => {
location.reload();
},
err => {
console.error(err);
}
);
Differential Revision: https://phabricator.services.mozilla.com/D56974
--HG--
extra : moz-landing-system : lando