I don't think these need invalidation of any sort since they only depend on
ancestors, and we recreate accessibles when the element's ancestor chain changes.
Differential Revision: https://phabricator.services.mozilla.com/D49408
--HG--
extra : moz-landing-system : lando
This moves the call to run_function_deprecated_, which ensures it is called at
least once prior to the thread exiting, to outside of the do/while loop. As
written, it is being called every time a message is received, causing desktop
capture frame rates on Windows to be higher than expected.
Differential Revision: https://phabricator.services.mozilla.com/D49412
--HG--
extra : moz-landing-system : lando
Bug 1586683 replaced the JS_FlattenString in the caller with JS_EnsureLinearString but
I wasn't aware of the nsDependentString vs nsDependentSubstring distinction.
This fixes assertion failures when starting the browser with non-null-terminated
JS strings.
Differential Revision: https://phabricator.services.mozilla.com/D49297
--HG--
extra : moz-landing-system : lando
This change removes the following specifiers in the `mochitest` manifest files:
- api >= 23
- api <= 17
- api == 22
Of the three, api >= 23 may present some risks, but `mochitest-media` suite does not appear to report any issues.
Differential Revision: https://phabricator.services.mozilla.com/D49337
--HG--
extra : moz-landing-system : lando
This is a wrapper around the `sqlite3_limit` interface that returns the
binding parameter limit. Adding this getter lets us clean up the inline
`SQLITE_MAX_VARIABLE_NUMBER` constants scattered around Places.
Differential Revision: https://phabricator.services.mozilla.com/D49071
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
With the additional tests running, task times increase; I have added one
more test chunk for android mochitest-plain.
These tests were identified from a random sampling of mochitest manifests;
I intend to enable more mochitests in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D48912
--HG--
extra : moz-landing-system : lando
Additionally, this fixes test dom/tests/mochitest/bugs/test_bug1530292.html
which fails if fission is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D47779
--HG--
extra : moz-landing-system : lando
This flips the direction in which the BrowserBridge actor is generally created
such that it is generally created in the parent and sent down to a child
process.
This is done by making the decision about what kind of switch to perform in the
parent, and sending messages down to child processes async to orchestrate these
process changes.
Process launching is changed to use an async `MozPromise`-returning API in this
patch, though the actual process launching still occurs synchronously. A future
patch will enable performing async process launching through the
NewOrUsedBrowserProcess mechanism.
I know of at least a few timing issues which exist with the new logic,
especially around the state of the BrowsingContext during the process
transition. I decided to not try to fix all of these issues in this patch, as
many are complex and will require changing how we manage the lifecycle of
BrowsingContext substantially. I do, however, think that the new logic is more
reliable and has fewer timing issues than the previous logic.
Differential Revision: https://phabricator.services.mozilla.com/D47310
--HG--
extra : moz-landing-system : lando
This is useful in part 3, where the initialization will need to be called from
multiple places.
Differential Revision: https://phabricator.services.mozilla.com/D47308
--HG--
extra : moz-landing-system : lando
This flag is only meant for window.open() stuff, so not relevant to iframes at
all.
This preserves the current fission behavior (which is quite broken) of always
showing scrollbars.
The way to control scrollbars for iframes (the scrolling attribute) is not
handled at all for Fission, I filed a bug and left a few FIXMEs.
Differential Revision: https://phabricator.services.mozilla.com/D49292
--HG--
extra : moz-landing-system : lando
Currently when checking if a window supports protected media it's up to the
caller interacting with a BrowserChild to check if a response is already
cached, to perform the check if needed, and to then set the cached response if a
call was made. This patch moves that logic internal to Browser child so that
callers need to only worry about interacting with a single function.
Differential Revision: https://phabricator.services.mozilla.com/D48585
--HG--
extra : moz-landing-system : lando
This leaves the testharness files, because they are used in various mochitests.
Differential Revision: https://phabricator.services.mozilla.com/D49132
--HG--
extra : moz-landing-system : lando
Add a new FIXUP_FLAG_PRIVATE_CONTEXT to nsIURIFixup, make it use the default
private search engine when it's set.
Update consumers to pass the new flag when necessary.
Differential Revision: https://phabricator.services.mozilla.com/D48741
--HG--
extra : moz-landing-system : lando
The XBL test is being removed because it was the only remaining consumer of
xbl's implements="interfacename" in the tree, and was triggering QI on elements
for that codepath.
I've verified that a try run that MOZ_CRASHes when the C++ binding
QueryInterface implementation is invoked is green with these changes.
Differential Revision: https://phabricator.services.mozilla.com/D48249
--HG--
extra : moz-landing-system : lando
This leaves the testharness files, because they are used in mochitest-chrome
tests in dom/animation/test.
Differential Revision: https://phabricator.services.mozilla.com/D49132
--HG--
extra : moz-landing-system : lando
In addition to the tests added before, which test the decoding of encoded
keys, this adds test for other member functions of Key.
Differential Revision: https://phabricator.services.mozilla.com/D39005
--HG--
extra : moz-landing-system : lando
This leaves the testharness files, because they are used in mochitest-chrome
tests in dom/animation/test.
Differential Revision: https://phabricator.services.mozilla.com/D49132
--HG--
extra : moz-landing-system : lando
I use `warningFlag` instead of `infoFlag` because even if the principal
writing-mode propagation is written in the spec, its effect might
surprise the developers.
Differential Revision: https://phabricator.services.mozilla.com/D48774
--HG--
extra : moz-landing-system : lando
We want to remove flat strings (JSFlatString). With this patch we only expose
linear strings (JSLinearString) to API consumers.
This is very mechanical for the most part, because code typically only cares
about linear strings and not the null-termination aspect.
CTypes's Library.cpp has some Windows-specific code where we relied on null-terminated
strings. This patch adds JS_CopyStringCharsZ for that use case.
Differential Revision: https://phabricator.services.mozilla.com/D48314
--HG--
extra : moz-landing-system : lando
This allows installing a SIGXCPU handler, which will simply set an atomic to
true when reached.
Another function allows querying this atomic.
Finally, another function allows demoting the current thread from real-time
priority.
This is per-process currently, as there is only one audio callback thread that
is set to RT scheduling per process, servicing all HTMLMediaElements and MSGs.
Whenever any of those go over the soft limit, the thread is demoted.
Differential Revision: https://phabricator.services.mozilla.com/D43404
--HG--
extra : moz-landing-system : lando
In ServiceWorkerPrivateImpl::SendFetchEvent, a heap-allocated AutoIPCStream can
point to a stack-allocated IPCStream (part of an IPCInternalRequest). If this
IPCStream is destroyed before the AutoIPCStream, the AutoIPCStream will have a
dangling pointer (and this is the case if SendFetchEvent is called when the
Service Worker's state is "activating" rather than "activated").
This patch moves around the logic to handle the AutoIPCStream's lifetime to
ensure it its lifetime is within its IPCStream's lifetime. The larger issue
might be that AutoIPCStream doesn't have inherent lifetime guarantees (it'll
definitely outlive its IPCStream if it points to its embedded one, but it
doesn't own any external IPCStreams it might point to).
Differential Revision: https://phabricator.services.mozilla.com/D48935
--HG--
extra : moz-landing-system : lando
IsCurrentInnerWindow() should only return true when we are the current inner
of our BrowsingContext, which has a longer lifetime than individual
GlobalWindowOuter instances. In particular, if our BrowsingContext has no
GlobalWindowOuter hanging off it, that means that currently it's hosting an
inner window from some other process and we are not the current inner. If it
_does_ have a GlobalWindowOuter hanging off it, it's possible that this is not
the same as our mOuterWindow, if the BrowsingContext navigated to a different
site and then navigated back to our site.
Therefore, we need to check that we are the current inner of whatever the
BrowsingContext's current GlobalWindowOuter is, if it has one at all.
Differential Revision: https://phabricator.services.mozilla.com/D48595
--HG--
extra : moz-landing-system : lando
It doesn't have any useful effect given the way Fission chooses processes, and
complicates the window.open logic in ways that are hard to maintain and cause
problems.
Differential Revision: https://phabricator.services.mozilla.com/D48749
--HG--
extra : moz-landing-system : lando
The new error message is still not great, but it's a lot better than having %s
as the description of what's going on.
Differential Revision: https://phabricator.services.mozilla.com/D47915
--HG--
extra : moz-landing-system : lando
When we have a parser-created iframe which starts out in-process, transitions
to remote, and then transitions back to in-process, we create separate
DocShells for the first and last in-process loads. Since both are
network-created, and have the same child index, they both try to add
themselves as children to their parent's SHistory at the same index. And since
the entry for the first DocShell already exists at that index when we try to
add the second, that triggers an assertion.
This isn't really ideal, but it is expected given the current state of session
history under Fission. It should hopefully be solved more gracefully when the
Fission-aware session history rewrite is done, but in the mean time, I think
we should just ignore the conflict, since it's expected.
Differential Revision: https://phabricator.services.mozilla.com/D48437
--HG--
extra : moz-landing-system : lando
The XBL test is being removed because it was the only remaining consumer of
xbl's implements="interfacename" in the tree, and was triggering QI on elements
for that codepath.
I've verified that a try run that MOZ_CRASHes when the C++ binding
QueryInterface implementation is invoked is green with these changes.
Differential Revision: https://phabricator.services.mozilla.com/D48249
--HG--
extra : moz-landing-system : lando
Notify VRActiveStatus after a the VREventObserver is created to prevent the VRManagerParent::GetVRActiveStatus race condition.
Call VRManager::Shutdown() when the app goes to background instead of calling it in the foreground event due to the inactivity timer.
Differential Revision: https://phabricator.services.mozilla.com/D48678
--HG--
extra : moz-landing-system : lando
e10s scenario:
1. An DOM element request fulscreen mode.
2. The request is redirected to the parent.
3. Parent enters fullscreen.
4. Parent notifies child that it has finished entering fullscreen.
5. Child goes fullscreen.
6. Then, child notifies parent that it has finished transitioning to fullscreen.
4. Finally, parent notify observers that fullscreen paint has finished.
Let's go into the details of how step 5 works in the above scenario.
5.a The element that made the request is set to fullscreen.
5.b Then, the document where that element lives is set to fullscreen as well as all of its ancestors until we reach the top level document. (see Document::ApplyFulscreen method)
Now in Fission world, we may have a request comming from an oop iframe. And it that case since we won't have to ancestor documents living in different content process(es), we will first notiy those content processes (one after another from bottom to top) to go fullscreen. Once they all do, the content process where the request originated will be told to enter fullscreen.
Differential Revision: https://phabricator.services.mozilla.com/D45972
--HG--
extra : moz-landing-system : lando
Database actors are force killed after 5 seconds if the child side doesn't
respond to the RequestAllowToClose message during shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D48899
--HG--
extra : moz-landing-system : lando
Implement the setActionHandler interface. The API will be enabled behind
a pref.
Depends on D45457
Differential Revision: https://phabricator.services.mozilla.com/D45458
--HG--
extra : moz-landing-system : lando
Implement the MediaMetadata interface. The API will be enabled behind a
pref.
Depends on D45456
Differential Revision: https://phabricator.services.mozilla.com/D45457
--HG--
extra : moz-landing-system : lando
Create dummy implementations for the MediaSession interfaces. The files
are generated by running `./mach webidl-example` with necessary changes
to make it buildable.
The internal implementations are blank in this patch. They will be done
in the following patches.
Due to some spec issues, the final implementations only support some
basic operations like "play" and "pause".
Differential Revision: https://phabricator.services.mozilla.com/D45456
--HG--
extra : moz-landing-system : lando
A forward declaration right before a definition is useless, and
ParseLazyURIValue is not implemented.
Differential Revision: https://phabricator.services.mozilla.com/D48760
--HG--
extra : moz-landing-system : lando
Implement the setActionHandler interface. The API will be enabled behind
a pref.
Differential Revision: https://phabricator.services.mozilla.com//D45458
Depends on D45457
--HG--
extra : histedit_source : 43cf16795b27126a96441b117c9bbfdf2aea6aa9
Implement the MediaMetadata interface. The API will be enabled behind a
pref.
Differential Revision: https://phabricator.services.mozilla.com//D45457
Depends on D45456
--HG--
extra : histedit_source : a572d4abe88c2b4cd8c03a0fadc6c7b30a8c8798
Create dummy implementations for the MediaSession interfaces. The files
are generated by running `./mach webidl-example` with necessary changes
to make it buildable.
The internal implementations are blank in this patch. They will be done
in the following patches.
Due to some spec issues, the final implementations only support some
basic operations like "play" and "pause".
Differential Revision: https://phabricator.services.mozilla.com//D45456
--HG--
extra : histedit_source : 2fc6e1e63347211cad3a19354a38040760c7ce0f
The first call to Extract() comes from MediaEncoderInitialized() and runs before
we dispatch the task to fire "start". With a very small timeslice (even 0), the
first call to Extract() could decide to push a blob, which is against the spec.
With this patch, the caller is in control of what time Extract() thinks "now"
is. This lets the particular call from MediaEncoderInitialized() gather data
into the blob through Extract() without being at risk of pushing a blob.
Differential Revision: https://phabricator.services.mozilla.com/D48842
--HG--
extra : moz-landing-system : lando
Create dummy implementations for the MediaSession interfaces. The files
are generated by running `./mach webidl-example` with necessary changes
to make it buildable.
The internal implementations are blank in this patch. They will be done
in the following patches.
Due to some spec issues, the final implementations only support some
basic operations like "play" and "pause".
Differential Revision: https://phabricator.services.mozilla.com/D45456
--HG--
extra : moz-landing-system : lando
On Android, decoded buffers need to be send back to MediaCodec in order to be
rendered and/or recycled. The current mechanism introduced in bug 1299068 only
works for playback(VideoData/VideoSink) but not WebRTC(VideoFrame/VideoOutput).
Move the callback to SurfaceTextureImage because VideoData and VideoFrame both
own that when using MediaCodec, and move the notification to VideoFrameContainer
for both VideoSink and VideoOutput pass frames there for compositing.
Differential Revision: https://phabricator.services.mozilla.com/D45771
--HG--
extra : moz-landing-system : lando
See the first patch's commit message to learn why we had to change the
PageInformation's IDs to BrowsingContextID and InnerWindowID.
Previously we were registering profiler PageInformation in the nsDocShell
methods. That was not the correct place to handle page loads correctly. That's
why we had to move the registration to WindowGlobalChild::SetDocumentURI and
WindowGlobalChild::ActorDestroy. In those functions we are sure that each
document URIs will come here only once.
Differential Revision: https://phabricator.services.mozilla.com/D47066
--HG--
extra : moz-landing-system : lando
We were keeping nsDocShell::mHistoryId and nsDocShell::mOSHE as keys. They
weren't quite good because:
1. While loading an iframe, they were being registered twice with the same
ids(for about:blank and the real URL) sometimes.
2. It wasn't possible to access to the parent mHistoryId and mOSHE from a child
processes if the parent is in a different process. That may not be the case for
now, but it will be after fission.
So we had to find other IDs to:
1. Determine the Tab of the frames.
2. Determine the URLs of the frames.
For the first use case, we were using nsDocShell::mHistoryId for that purpose
but that was wrong. The closest thing that we can get to a tab ID is
BrowsingContext ID because they don't change after a navigation. But iframes
have different BrowsingContext's, so we still need to create a tree to
construct a tab content. That can be either in the front-end or capture time.
For the second use case, we were using a key pair of mHistoryId and mOSHE. We
now chose to keep inner window IDs for that purpose. Inner window IDs are
unique for each navigation loads because inner window correspond to each JS
window global objects. That's why we can use that without any problem. But one
problem is that we cannot handle `history.pushState` and `history.replaceState`
changes with that change since window global objects won't change during those.
But that was the best thing we can do after fission. So this will be a small
sacrifice for us to keep that functionality working after fission.
In that patch we also remove the registration/unregistration calls. We are
going to add those calls in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D47065
--HG--
extra : moz-landing-system : lando
This method turned out to only be used for tracing wrapper cached things. The wrapper cache has its own way of implementing barriers and contains a raw JSObject pointer. Changing this trace method to take an nsWrapperCache pointer (effectively a JSObjct**) enforces correct use of Heap<T> for other TraceCallbacks callers.
Differential Revision: https://phabricator.services.mozilla.com/D48693
--HG--
extra : moz-landing-system : lando
Looks like an oversight from all the way back to bug 806506.
Depends on D48538
Differential Revision: https://phabricator.services.mozilla.com/D48539
--HG--
extra : moz-landing-system : lando
Web Share base implementation just of DOM stuff - working together with @saschanaz.
@Baku, we would greatly appreciate your review.
-Nika, as she is traveling.
Differential Revision: https://phabricator.services.mozilla.com/D44598
--HG--
extra : moz-landing-system : lando
We should have a basic test where do a simply request and revoke audio focus for same controller.
Differential Revision: https://phabricator.services.mozilla.com/D47372
--HG--
extra : moz-landing-system : lando
`TestMultipleAudioFocusNums` is used to test whether we can increase the amount of the audio focus when we don't enable audio focus management. As we won't handle the audio competing in this situation, so we allow multiple controllers owing audio focus at the same time.
However, if we enable audio focus management, we would start to handle audio competing and ensure that only one controller can own audio focus at a time. As it involves multiple components, we are not able to test it by simply using `AudioFocusManager`'s APIs.
Therefore, we should have two separate tests to test the behavior of owning audio focus when enabling or disabling audio focus management.
Differential Revision: https://phabricator.services.mozilla.com/D47371
--HG--
extra : moz-landing-system : lando
The changes are just cleanup for member variables/methods that should
be private to ServiceWorkerManager.
Differential Revision: https://phabricator.services.mozilla.com/D48181
--HG--
extra : moz-landing-system : lando
Also replace ServiceWorkerManager shutdown logic's normal for-loops with
range-based for-loops.
Differential Revision: https://phabricator.services.mozilla.com/D48179
--HG--
extra : moz-landing-system : lando
- Listen for observer topics in the parent-process when in parent intercept mode
- Remove an extra postMessage call (and the corresponding message handler)
Differential Revision: https://phabricator.services.mozilla.com/D44513
--HG--
extra : moz-landing-system : lando
When XBL is disabled, no code in dom/xbl will be built. Also, adds ifdefs
to remove any of the XBL related code elsewhere. There's definitely more
that can be done here, but I think it's better to wait to do the rest of
the cleanup when we actually remove the code.
Depends on D45612
Differential Revision: https://phabricator.services.mozilla.com/D45613
--HG--
extra : moz-landing-system : lando
Previously, Service Workers could spawn in a process that isn't subscribed
to permission updates, which could happen if that process hadn't loaded any
same-origin documents. To address this, parent-process logic for spawning
Service Workers would snapshot the permissions state to be sent to a content
process.
Unfortunately, this approach could lead to outdated, unsynchronized permissions.
Note that nsIPermissionManager::SetPermissionsWithKey is only used to initialize
permissions for a given key and is a no-op if already called with the same key
in a given process. As a result, the following sequence of events could happen:
Assume a content process CP that isn't subscribed to permission changes for an
origin A:
1) Parent process decides to spawn an origin A Service Worker in CP,
snapshotting a value V for permission P.
2) The Service Worker is spawned in CP, setting CP's permission manager's
permission P to value V (for origin A).
3) Parent process updates its permission P to a value A', which is not
broadcasted to CP (because it's not subscribed).
4) By now, the initial Service Worker has been terminated, and the parent
process decides once again to spawn an origin A Service Worker in CP.
5) The Service Worker is spawned in CP, but the call to SetPermissionsWithKey
is a no-op, leaving CP1 with a mismatched value for permission P.
An additional scenario is if the parent process updates a permission during a
remote Service Worker's lifetime.
This patch, which would subscribe CP1 to permission updates when the parent
process knows a Service Worker would be spawned in CP1, prevents these problems.
Differential Revision: https://phabricator.services.mozilla.com/D48620
--HG--
extra : moz-landing-system : lando
Added playout-delay RTP header extension for video to JsepSessionImpl::SetupDefaultRtpExtensions.
This ensures that this extension will be preserved when generating an answer to an offer (by a sending peer) containing it.
Also updated JsepSessionTest to include a test verifying that the expected default audio and video extensions are set.
Differential Revision: https://phabricator.services.mozilla.com/D47689
--HG--
extra : moz-landing-system : lando
This patch does several things. Because Workers aren't on the main thread,
many of the things done are in the name of off main thread access.
1) Changes a parameter in IsEvalAllowed from a nsIPrincipal to a bool.
We only used the principal to determined if it was the System Principal.
Principals aren't thread safe and can only be accessed on Main Thread, so
if we passed a Principal in, we would be in error. Instead only pass in
the bool which - for workers - comes from a thread-safe location.
2) Separates out the Telemetry Event Recording and sending a message to the
console into a new function nsContentSecurityUtils::NotifyEvalUsage. (And
creates a runnable that calls it.)
We do this because we will need to only call this method on the main thread.
Telemetry Event Recording has only ever been called on the Main Thread.
While I possibly-successfully cut it over to happen Off Main Thread (OMT)
by porting preferences to StaticPrefs, I don't know if there were other
threading assumptions in the Telemetry Code. So it would be much safer to
just continue recording Event Telemetry on the main thread.
Sending a message to the console requires calling GetStringBundleService()
which requires main thread. I didn't investigate if this could be made
thread-safe, I just threw it onto the main thread too.
If, in IsEvalAllowed, we are on the main thread - we call NotifyEvalUsage
directly. If we are not, we create a runnable which will then call
NotifyEvalUsage for us on the main thread.
3) Ports allow_eval_with_system_principal and allow_eval_in_parent_process
from bools to RelaxedAtomicBool - because we now check these prefs OMT.
4) In RuntimeService.cpp, adds the call to IsEvalAllowed.
5) Add resource://gre/modules/workers/require.js to the allowlist of eval
usage. This was the script that identified this gap in the first place.
It uses eval (twice) for structural reasons (scope and line number
massaging.) The contents of the eval are the result of a request to a
uri (which may be internal, like resource://). The whole point of this
is to implement a CommonJS require() api.
This usage of eval is safe because the only way an attacker can inject
into it is by either controlling the response of the uri request or
controlling (or appending to) the argument. If they can do that, they
are able to inject script into Firefox even if we cut this usage of eval
over to some other type of safe(r) script loader.
Bug 1584564 tracks making sure calls to require.js are safe.
6) Adds cld-worker.js to the allowlist. Bug 1584605 is for refactoring that
eval usage, which is decidedly non-trivial.
7) Does _not_ enforce the eval restrictions for workers. While I've gotten
try to be green and not throw up any instances of eval-usage by workers,
it is much safer to deploy this is Telemetry-only mode for Workers for
a little bit to see if anything pops up from the Nightly population.
Bug 1584602 is for enforcing the checks.
Differential Revision: https://phabricator.services.mozilla.com/D47480
--HG--
extra : moz-landing-system : lando
In that case, the flat tree cannot possibly be changing, so we don't really need
to invalidate anything. This, in theory, is just a really minor optimization.
In practice however, the browser chrome needs it, at least for now, because XUL
elements get frames really early (because we don't have lazy frame construction
for XUL, bug 1584935), and because destroying some kinds of frames (like panels)
does have side effects (they're popups), even though ideally they shouldn't.
Differential Revision: https://phabricator.services.mozilla.com/D48428
--HG--
extra : moz-landing-system : lando
As we would calculate time difference between frames by checking their timestamp, so we would always ensure that image has valid timestamp.
Differential Revision: https://phabricator.services.mozilla.com/D48034
--HG--
extra : moz-landing-system : lando
Chrome and old Edge at least seem to have this behavior, and this way the testcase on the bug doesn't trigger click anymore since
we enter dnd mode and get dragleave etc. events.
Manually tested on linux and Windows, and annyg tested on Mac
Update test_dragstart.html's draggable=true test to follow the pattern used by other tests
Differential Revision: https://phabricator.services.mozilla.com/D48208
--HG--
extra : moz-landing-system : lando
Previously we assumed that we could trust the `OnLocationChange`,
`OnStateChange`, and `OnSecurityChange` IPC messages from the BrowserChild to
BrowserParent to always contain their optional data if the message was
top-level. However, if a content process becomes compromised, this could be
used to DOS the parent process by maliciously sending these messages to the
parent process with invalid data.
Now we explicitly check that the data is valid before derefing.
Differential Revision: https://phabricator.services.mozilla.com/D48423
--HG--
extra : moz-landing-system : lando
Chrome and old Edge at least seem to have this behavior, and this way the testcase on the bug doesn't trigger click anymore since
we enter dnd mode and get dragleave etc. events.
Manually tested on linux and Windows, and annyg tested on Mac
Differential Revision: https://phabricator.services.mozilla.com/D48208
--HG--
extra : moz-landing-system : lando
Because that's how such spans are generated in `HTMLEditor::InsertAsPlaintextQuotation`.
Differential Revision: https://phabricator.services.mozilla.com/D46919
--HG--
extra : moz-landing-system : lando
If LSRequestChild actor is unexpectedly destroyed, the nested event loop runs
until the timer fires. This patch improves that by calling the callback in
LSRequestChild::ActorDestroyed which immediatelly finishes RequestHelper and
finishes the nested event loop in the end too.
Differential Revision: https://phabricator.services.mozilla.com/D48194
--HG--
extra : moz-landing-system : lando
See https://groups.google.com/forum/#!topic/mozilla.dev.platform/70NFnet82cU
This commit introduces a new mathml.xlink.disabled option to disable support
for XLink attributes on MathML elements together with a use counter and
deprecation warning when support is enabled. For now, support is only disabled
in Nightly.
In the past, we relied on custom MathML deprecation warnings but those are
removed here. Corresponding tests for these legacy warning messages are
also removed from test_bug553917.html.
link-1.xhtml is run with XLink support enabled (since it checks xlink:href)
while browser_contentAltClick.js and browser_contentAreaClick.js are updated
to instead check MathML links (i.e. href instead of xlink:href).
Differential Revision: https://phabricator.services.mozilla.com/D43332
--HG--
extra : moz-landing-system : lando
These still fail or timeout because of missing platform features, but at least
the tests will pass once those platform features are fixed after this.
Differential Revision: https://phabricator.services.mozilla.com/D48221
--HG--
extra : moz-landing-system : lando
This does many things:
1) stops producing (and consuming) `FennecJNI*` JNI wrappers
2) removes the :app and :thirdparty Gradle projects
3) removes relevant pieces of the Gradle target configuration
4) updates lints
5) purges old configurations
After this commit, the `mobile/android` project/application builds
only GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D46536
--HG--
extra : moz-landing-system : lando
The signatures were updated in the previous patch to hand us the raw,
uncopied buffers. This just adjusts the callsites to match.
Differential Revision: https://phabricator.services.mozilla.com/D34653
--HG--
extra : moz-landing-system : lando
This just splits out the InputBuffer and OutputBuffer helper classes
to make it cleaner for the StartupCache to include them.
Differential Revision: https://phabricator.services.mozilla.com/D34651
--HG--
extra : moz-landing-system : lando
This will not behave exactly the same if we had previously written bad
data for the entry that would fail to decompress. I imagine this is rare
enough, and the consequences are not severe enough, that this should be
fine.
Differential Revision: https://phabricator.services.mozilla.com/D30643
--HG--
extra : moz-landing-system : lando
Use test1.mochi.test:8888 instead of example.org so that the innermost iframe is
still same-compartment with the top-level page.
Differential Revision: https://phabricator.services.mozilla.com/D48192
--HG--
extra : moz-landing-system : lando
This patch does two things:
1) Extracts data before firing "start", instead of after, so that any
`requestData()` or timeslice-based "dataavailable" event fired immediately
after "start" contains data.
2) Sets mLastBlobTimeStamp on encoder initialization instead of session
construction, so that any "dataavailable" events are held back until some
actual data has been gathered.
Differential Revision: https://phabricator.services.mozilla.com/D46466
--HG--
extra : moz-landing-system : lando
With spec compliant mime type handling we no longer fire "error" on start for a
audio-only recording of a (currently) video-only MediaStream.
This patch adapts the test to more accurately name what we originally wanted to
test - that pause() after an error doesn't crash but throws. It does this by
triggering another kind of error, one that happens because we try to remove
the recorded track from the recorded stream. We still keep the behavior of
start()ing the recording before any supported tracks are available, because we
support that.
To clarify what this test is actually testing, this patch also modernizes the
code with async/await to linearize the testing of events and their order.
Differential Revision: https://phabricator.services.mozilla.com/D17811
--HG--
rename : dom/media/test/test_mediarecorder_unsupported_src.html => dom/media/test/test_mediarecorder_onerror_pause.html
extra : moz-landing-system : lando
This test relied on us choosing to record audio/ogg because of the only audio
track, which would fail and result in an error with ogg support disabled.
We now per spec select mime type synchronously on construction instead of after
detecting the stream's tracks - and so fall back to video/webm when the mime
type is defaulted. With this the test times out because we're recording fine.
When disabling also webm encoding we follow the spec's "note that this case is
essentially equivalent to leaving up to the UA the choice of container and
codecs on constructor", and choose some unknown mime type that is not supported
(none are), thus ending up throwing NotSupportedError.
Not much remains of this test with these changes, and what actually remains is
covered by other tests, which warrants removal.
Differential Revision: https://phabricator.services.mozilla.com/D17810
--HG--
extra : moz-landing-system : lando
This is the last step to making the MediaRecorder's mime type handling up to
spec, and has a real effect only if the constrained mime type is empty, or doesn't
contain any codecs.
Differential Revision: https://phabricator.services.mozilla.com/D17809
--HG--
extra : moz-landing-system : lando
This leaves out support for extending the mime type with the selected container
and codecs, and support in MediaEncoder for using a specific mime type.
Differential Revision: https://phabricator.services.mozilla.com/D46463
--HG--
extra : moz-landing-system : lando
This aligns it better with MediaRecorder's timeslice which was changed from
int32 to uint32 earlier.
Differential Revision: https://phabricator.services.mozilla.com/D41586
--HG--
extra : moz-landing-system : lando
This brings the MediaRecorder constructor and start() to spec on most parts
except mime type handling (bug 1512175). The flow is also improved to better
follow along in the algorithms of the spec.
Differential Revision: https://phabricator.services.mozilla.com/D41585
--HG--
extra : moz-landing-system : lando
Unlike WorkletPrincipal, a WorkerPrincipal had been a simple static object shared by
all Workers. We never needed to consult it about an individual Worker before. Now we
do. So we cut it over from a static object to individual objects for each Worker.
We have an off main thread access problem for the Principal however, WorkerPrivate
has a method UsesSystemPrincipal that returns a bool that was initialized from the
Principal on the main thread. We copy that pattern and add a
UsesAddonOrExpandedAddonPrincipal method that will be called by the
isSystemOrAddonPrincipal method we must implement so we can inheirt from JSPrincipal.
Differential Revision: https://phabricator.services.mozilla.com/D47476
--HG--
extra : moz-landing-system : lando
WorkletPrincipal inherits JSPrincipals so we need to add the isSystemOrAddonPrincipal
method to it. As of Bug 1578623 rev a83797ed249c - Worklets are always NullPrincipal,
so we can just return false.
Differential Revision: https://phabricator.services.mozilla.com/D47475
--HG--
extra : moz-landing-system : lando
In a future commit we will tie this boolean to its own preference value, but here we
initialize it with the same value as the wasm boolean.
We also update wasm::HasSupport to check the to-be-added isSystemOrAddonPrincipal()
method on JSPrincipals to determine which member (wasm or wasmForTrustedPrinciples)
to consult.
Differential Revision: https://phabricator.services.mozilla.com/D47472
--HG--
extra : moz-landing-system : lando
CreationOptions are intended to be immutable and not change during realm operation.
Behaviors change, and clamping/jittering should reside on behaviors.
Differential Revision: https://phabricator.services.mozilla.com/D43296
--HG--
extra : moz-landing-system : lando
The changes are just cleanup for member variables/methods that should
be private to ServiceWorkerManager.
Depends on D48179
Differential Revision: https://phabricator.services.mozilla.com/D48181
--HG--
extra : moz-landing-system : lando
Also replace ServiceWorkerManager shutdown logic's normal for-loops with
range-based for-loops.
Depends on D43170
Differential Revision: https://phabricator.services.mozilla.com/D48179
--HG--
extra : moz-landing-system : lando
- Listen for observer topics in the parent-process when in parent intercept mode
- Remove an extra postMessage call (and the corresponding message handler)
Differential Revision: https://phabricator.services.mozilla.com/D44513
--HG--
extra : moz-landing-system : lando
Because it's possible to have the IPC fail when checking if MediaKeySystemAccess
should be allowed, we should gracefully handle the IPC failure case. If we don't
gracefully handle here, closing the tab during requestMediaKeySystemAccess can
result in crashing the content process.
Differential Revision: https://phabricator.services.mozilla.com/D48116
--HG--
extra : moz-landing-system : lando
Depends on D47963
This workaround was only used by DevTools when using a chrome frame. DevTools toolbox now always uses frame type=content, so the workaround can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D47964
--HG--
extra : moz-landing-system : lando
This flips the direction in which the BrowserBridge actor is generally created
such that it is generally created in the parent and sent down to a child
process.
This is done by making the decision about what kind of switch to perform in the
parent, and sending messages down to child processes async to orchestrate these
process changes.
Process launching is changed to use an async `MozPromise`-returning API in this
patch, though the actual process launching still occurs synchronously. A future
patch will enable performing async process launching through the
NewOrUsedBrowserProcess mechanism.
I know of at least a few timing issues which exist with the new logic,
especially around the state of the BrowsingContext during the process
transition. I decided to not try to fix all of these issues in this patch, as
many are complex and will require changing how we manage the lifecycle of
BrowsingContext substantially. I do, however, think that the new logic is more
reliable and has fewer timing issues than the previous logic.
Differential Revision: https://phabricator.services.mozilla.com/D47310
--HG--
extra : moz-landing-system : lando
This is useful in part 3, where the initialization will need to be called from
multiple places.
Differential Revision: https://phabricator.services.mozilla.com/D47308
--HG--
extra : moz-landing-system : lando
See https://groups.google.com/forum/#!topic/mozilla.dev.platform/vwAkuZIEhnY
* Introduce a new preference option to disable menclose's "radical" notation.
* Disable the notation in Nightly and when running WPT tests.
* Enable the notation in other channels together with a counter and
deprecation warning.
* Update WPT test legacy-menclose-radical-notation.html
- Fix test: "radical" should be equivalent to "", which is not the same as
the default value "longdiv".
See https://github.com/mathml-refresh/mathml/issues/144
- Add a test "box radical" which should be equivalent to "box".
- Remove failure expectation.
* Enable the radical notation for MathML reftests testing it.
Differential Revision: https://phabricator.services.mozilla.com/D46721
--HG--
extra : moz-landing-system : lando
The original test case doesn't crash reliably but the test case in this commit
crashes 100% locally without this fix.
Differential Revision: https://phabricator.services.mozilla.com/D48009
--HG--
extra : moz-landing-system : lando
See https://groups.google.com/forum/#!topic/mozilla.dev.platform/vwAkuZIEhnY
* Introduce a new preference option to disable menclose's "radical" notation.
* Disable the notation in Nightly and when running WPT tests.
* Enable the notation in other channels together with a counter and
deprecation warning.
* Update WPT test legacy-menclose-radical-notation.html
- Fix test: "radical" should be equivalent to "", which is not the same as
the default value "longdiv".
See https://github.com/mathml-refresh/mathml/issues/144
- Add a test "box radical" which should be equivalent to "box".
- Remove failure expectation.
* Enable the radical notation for MathML reftests testing it.
Differential Revision: https://phabricator.services.mozilla.com/D46721
--HG--
extra : moz-landing-system : lando
This test fails intermittently on geckoview; when it fails, many later-running
tests fail also, causing some confusion in bug classification.
Differential Revision: https://phabricator.services.mozilla.com/D47932
--HG--
extra : moz-landing-system : lando
It was complaining about
"unrooted '<returnvalue>' of type 'JSObject*' live across GC call at dom/base/Element.cpp:588"
Where the GC call is:
Function '_ZN7mozilla3dom7Element10WrapObjectEP9JSContextN2JS6HandleIP8JSObjectEE$JSObject* mozilla::dom::Element::WrapObject(JSContext*, JS::Handle<JSObject*>)' has unrooted '<returnvalue>' of type 'JSObject*' live across GC call '_ZN6RefPtrI12nsXBLBindingED1Ev$RefPtr<T>::~RefPtr() [with T = nsXBLBinding]' at dom/base/Element.cpp:588
Element.cpp:588: Assign(64,65, return := __temp_29**)
Element.cpp:588: Call(65,66, binding.~__dt_comp ()) [[GC call]]
Element.cpp:588: Call(66,67, principal.~__dt_comp ())
Element.cpp:588: Call(67,68, uri.~__dt_comp ())
Element.cpp:588: Call(68,69, style.~__dt_comp ())
Element.cpp:588: Call(69,70, obj.~__dt_comp ())
Element.cpp:589: [[end of function]]
GC Function: _ZN6RefPtrI12nsXBLBindingED1Ev$RefPtr<T>::~RefPtr() [with T = nsXBLBinding]
RefPtr<T>::~RefPtr() [with T = nsXBLBinding] [[base_dtor]]
static void RefPtr<T>::ConstRemovingRefPtrTraits<U>::Release(U*) [with U = nsXBLBinding; T = nsXBLBinding]
static void mozilla::RefPtrTraits<U>::Release(U*) [with U = nsXBLBinding]
uint32 nsXBLBinding::Release()
uint64 nsCycleCollectingAutoRefCnt::decr(void*, nsCycleCollectionParticipant*, uint8*) [with void (* suspect)(void*, nsCycleCollectionParticipant*, nsCycleCollectingAutoRefCnt*, bool*) = NS_CycleCollectorSuspect3; uintptr_t = long unsigned int]
NS_CycleCollectorSuspect3
nsCycleCollector.cpp:void SuspectAfterShutdown(void*, nsCycleCollectionParticipant*, nsCycleCollectingAutoRefCnt*, uint8*)
nsCycleCollectionParticipant.DeleteCycleCollectable
void nsIContent::cycleCollection::DeleteCycleCollectable(void*)
nsIContent.DeleteCycleCollectable
unresolved nsIContent.DeleteCycleCollectable
I don't think the analysis is right since the Rooted<> thing will go out of the
scope after the RefPtr.
MANUAL PUSH: Bustage fix for broken (I think) analysis
People keep shooting themselves in the feet because of this codepath and writing
slow code.
There are just a few elements with bindings left, so just check those.
Also simplify a bit the code. The XUL element + tagname check should be pretty
fast now, and ComputedStyle objects no longer keep weak pointers to pres
contexts and such, so can be safely kept on a RefPtr across an style flush.
Differential Revision: https://phabricator.services.mozilla.com/D47995
--HG--
extra : moz-landing-system : lando
I'm not sure what if there's a preference either way, but all the other globals in nsJSEnvironement.cpp are static so I made the CycleCollectorStats global static too.
Differential Revision: https://phabricator.services.mozilla.com/D47919
--HG--
extra : moz-landing-system : lando
This needs to be defined before FireForgetSkippable for the subsequnt patches.
Differential Revision: https://phabricator.services.mozilla.com/D47918
--HG--
extra : moz-landing-system : lando
This mostly updates the bindings to the current state.
No actual logic backing them yet.
*Note*: the IDL does *not* need to be checked for matching the upstream spec precisely at this stage. The upstream is evolving, we just need to update in order to start integrating the implementation. What needs to be checked is - how C++ represents the IDL, esp with regards to derived classes, events, and hierarchies.
The trickiest points, arguably, are:
- WebGPU -> GPU prefix change
- the goop for interfaces that are not final
Differential Revision: https://phabricator.services.mozilla.com/D46166
--HG--
rename : dom/webgpu/InputState.cpp => dom/webgpu/DeviceLostInfo.cpp
rename : dom/webgpu/Fence.h => dom/webgpu/DeviceLostInfo.h
rename : dom/webgpu/BlendState.cpp => dom/webgpu/OutOfMemoryError.cpp
rename : dom/webgpu/LogEntry.h => dom/webgpu/OutOfMemoryError.h
rename : dom/webgpu/BindGroup.h => dom/webgpu/ProgrammablePassEncoder.cpp
rename : dom/webgpu/BlendState.cpp => dom/webgpu/RenderBundle.cpp
rename : dom/webgpu/BlendState.h => dom/webgpu/RenderBundle.h
rename : dom/webgpu/AttachmentState.cpp => dom/webgpu/ValidationError.cpp
rename : dom/webgpu/AttachmentState.h => dom/webgpu/ValidationError.h
extra : moz-landing-system : lando
Since unions can now end up a in binding header, it's only a problem when the
two dictionaries are in one header and the union is in a different one. If all
three are in the same header, for example, there is no issue.
Differential Revision: https://phabricator.services.mozilla.com/D47195
--HG--
extra : moz-landing-system : lando
Since unions can now end up a in binding header, it's only a problem when the
two dictionaries are in one header and the union is in a different one. If all
three are in the same header, for example, there is no issue.
Differential Revision: https://phabricator.services.mozilla.com/D47195
--HG--
extra : moz-landing-system : lando
AudioNodeStream is a subclass of MediaStream, which now exposes a
public const mSampleRate member.
Differential Revision: https://phabricator.services.mozilla.com/D47688
--HG--
extra : moz-landing-system : lando
This change mainly removes the `mTracks` member from MediaStream and moves all
associated members up a level, so that a MediaStream in practice represents a
single track.
Classes will be renamed in a future patch to reflect this.
Other changes include:
The new `mEnded` member of MediaStream changes meaning to only become true when
all data in the stream has been processed. It stems from
StreamTracks::Track::mEnded which used to become true as soon as the last bit of
data had been added to a track, and there could still be data in the track that
would get processed in future iterations. We are moving towards not having any
future data in tracks, which is why this change is ok to make -- keeping the old
behavior will soon not make sense.
TrackUnionStream is changed to no longer take a list of streams as input and
forward the union of their tracks to itself. Instead it's limited to having one
track as input at a time.
The autofinishing functionality that TrackUnionStream had before has been
transformed into an autoending functionality to allow it to defer ending until
its been told that it's ok to end through the control API. This lets a single
TrackUnionStream span the lifetime of multiple inputs, which will be useful for
making DecodedStream spec compliant with HTMLMediaElement::CaptureStream(), and
for implementing the currently discussed MediaRecorder::ReplaceTrack(), to name
a few potential use cases.
AudioNodeStreams used to only have a track (and thus an AudioSegment) if the
EXTERNAL_OUTPUT flag was enabled on them. With all MediaStreams now representing
a track, AudioNodeStreams inherently have an AudioSegment as a member. It is
however only used with data if the EXTERNAL_OUTPUT flag is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D45821
--HG--
extra : moz-landing-system : lando
The stream order does not depend on streams' finished state, so these calls are
unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D47687
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Frederic Wang
Dzmitry Malyshau
Dan Minor
Cosmin Sabou
Jan de Mooij
Jean-Yves Avenard
Marcos Cáceres
Edwin Takahashi
Lina Cambridge
Geoff Brown
Edgar Chen
Anny Gakhokidze
Ehsan Akhgari
Kris Taeleman
Bobby Holley
Nika Layzell
Coroiu Cristina
Daniel Varga
Csoregi Natalia
Bryce Seager van Dyk
Ms2ger
shindli
Narcis Beleuzu
arthur.iakab
Razvan Maries
Dorel Luca
Jorg K
Marco Bonardo
Boris Zbarsky
Andreas Farre
Simon Giesecke
Ting-Yu Lin
Andreea Pavel
Paul Adenot
Perry Jiang
Kris Maglione
Imanol Fernandez
Abdoulaye Oumar Ly
Mirko Brodesser
Sebastian Hengst
John Dai
Sylvestre Ledru
Jan Varga
Chun-Min Chang
Matt Woodrow
Luca Greco
Oana Pop Rus
Andreas Pehrson
John Lin
Nazım Can Altınova
Brian Hackett
Jon Coppeard
Christoph Kerschbaumer
Thomas Nguyen
Marcos Cáceres
Gijs Kruitbosch
Tim Nguyen
Brindusan Cristian
alwu
Brendan Dahl
Alexander J. Vincent
Janice Shiu
Michael Froman
Emma Malysz
Andreas Schuler
Matthew Gregan
Tom Ritter
Tom Tung
Liang-Heng Chen
Alexander Surkov
Olli Pettay
Barret Rennie
Ricky Stewart
Bogdan Tara
Sebastian Streich
Valentin Gosu
aardgoose
Nick Alexander
Doug Thayer
Jason Laster
Julian Descottes
Hiroyuki Ikezoe
Jonathan Kingston
Byron Campen [:bwc]
Nico Grunbaum
Gurzau Raul
Andrew Swan
Tom Tung