* wpt runs chrome priv for a subset of tests (mostly things testing toolkit chrome stuff), but it's still in the content process
* we only ever hit this case if the test is explicitly loaded as chrome. originally added for a couple osx tests at https://bugzilla.mozilla.org/show_bug.cgi?id=1465457. then expanded for all xul tests at https://bugzilla.mozilla.org/show_bug.cgi?id=1557371
* so what we used to do here is run xul/xbl in the content process (not chrome priv)
* the change here is that with our chrome Custom Elements we need to run with chrome priv for https://searchfox.org/mozilla-central/rev/4218cb868d8deed13e902718ba2595d85e12b86b/toolkit/components/processsingleton/CustomElementsListener.jsm#16 to load the elements
* so we made it explicit. the alternative at the time was to change wpt harness to load these tests in parent process, but it was too complex for what we needed (discussed with dbaron)
* this parentprocess check was meant kind of as an optimization so that we wouldn't have to check priv on random pages. but (a) that's short circuited anyway by the xul elem check and (b) this is only called when attachShadow is called on a non-html element so not in any kind of hot path
Differential Revision: https://phabricator.services.mozilla.com/D46310
--HG--
extra : moz-landing-system : lando
Assuming our caller didn't mess up passing the reference (and code inspection
suggests callers did not thus mess up), we should not have null when we take a
pointer to the reference.
Differential Revision: https://phabricator.services.mozilla.com/D46506
--HG--
extra : moz-landing-system : lando
CubebDeviceEnumerator already knows when an audio device changes. It is enhanced to allow listeners/observers registration and to create notifications when that happens. Also, it is hooked to the existing notification path.
On a minor note, it has been revisited the way the enumerator is touched in MediaEngineWebRTC class.
Differential Revision: https://phabricator.services.mozilla.com/D46271
--HG--
extra : moz-landing-system : lando
DeviceChangeCallback class implements the observer pattern. However, the role of the observer and the subject is integrated into the same class which makes use of virtual methods to allow a separation of the roles. This makes code reading difficult. Also, it does not allow from a class to inherit only the observer role or the subject role. This patch breaks the DeviceChangeCallback class into two classes according to the observer or subject functionality.
Differential Revision: https://phabricator.services.mozilla.com/D46270
--HG--
extra : moz-landing-system : lando
This patch nulls out a Document's promises when it is destroyed to break cycles going through them and ensure Documents are cleaned up sooner.
Differential Revision: https://phabricator.services.mozilla.com/D46286
--HG--
extra : moz-landing-system : lando
It appears possible for data eviction to take place despite the manager not
currently having any buffered ranges. This shouldn't happen, but if it can if
the buffers have become full with 0 duration data. This patch attempts to
mitigate that case by removing all coded frames. This prevents a bad access on
the buffered ranges and should clear up space in the buffers to append more
data.
Differential Revision: https://phabricator.services.mozilla.com/D44711
--HG--
extra : moz-landing-system : lando
Similar to MozPromise::FromGeckoResult.
Allows to create a MozPromise that will be resolved/rejected when the JS promise does the same.
It would be nice to be able to chain the two promise types, but it would be an additional effort.
MozPromise::FromDomPromise is limited to primitive types only and the reject value type must be nsresult.
Differential Revision: https://phabricator.services.mozilla.com/D46017
--HG--
extra : moz-landing-system : lando
Now that we count them, I think we should do this.
This property is pretty painful for various reasons:
* It's a pretty awkward non-standard property.
* Has a pretty short name, so people use it instead of the standard
alternatives.
* We cannot really even implement it easily anyhow, without breaking a whole
bunch of stuff, because pages do things like:
```
myelement {
zoom: 0.5;
-moz-transform: scale(0.5);
transform-origin: 0 0;
}
```
For now this is only recorded when CSS use counters are enabled (Nightly for
now), but I want to change it once bug 1578661 is in central.
The hope is that this warning slightly raises awareness of this property not
being standard. You get a CSS parsing error in the console, but those are
usually too noisy and disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D46430
--HG--
extra : moz-landing-system : lando
Just use conventions properly. As much as I dislike it.
I wanted to do it because I wanted to add a console message on load for a few
situations (bug 1582374), but I found a better place to put it.
Differential Revision: https://phabricator.services.mozilla.com/D46431
--HG--
extra : moz-landing-system : lando
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)
Differential Revision: https://phabricator.services.mozilla.com/D45162
--HG--
extra : moz-landing-system : lando
We log to MOZ_LOG, report an error to the console, send telemetry, and in debug builds - crash
Differential Revision: https://phabricator.services.mozilla.com/D45055
--HG--
extra : moz-landing-system : lando
This avoids relying on the accessibility.tabfocus
pref having been set by a previous test.
Differential Revision: https://phabricator.services.mozilla.com/D46374
--HG--
extra : moz-landing-system : lando
The ideal situation for media control should be incooperated with the audio competition so that we only have to control one controller.
However, if it's multiple controllers at the same time, we would tend to only control the last one in order to reduce confustion.
Ex. If we pause controller A first, and then start controller B. So what should we do when we press `play/pause` hardware key? To resume controller A or to stop controller B, or do both things at the same time?
Differential Revision: https://phabricator.services.mozilla.com/D43315
--HG--
extra : moz-landing-system : lando
In order to receive platform level media hardward keys event, we create a `MediaHardwareKeysEventSource` which is used to implement intercepting those events according to different platforms.
We can add a `MediaHardwareKeysEventListener` onto `MediaHardwareKeysEventSource`, so that we can get notification whenever hardware media keys are being pressed.
`MediaHardwareKeysManager` is used to encapsulate all these details, it would create a source and corresponding listener.
Differential Revision: https://phabricator.services.mozilla.com/D43313
--HG--
extra : moz-landing-system : lando
C'est fini. Now to do the same with the unimplemented ones remains, but it
should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D44698
--HG--
extra : moz-landing-system : lando
By reporting the properties in MappedAttrParser that we used to (the test relies
on counting those), and by adjusting the histogram name to the new thing.
Differential Revision: https://phabricator.services.mozilla.com/D44697
--HG--
extra : moz-landing-system : lando
And add them to the UseCounter enum. Also add some sanity-check assertions that
the reporting code relies on.
This works much like the deprecated operation list.
Differential Revision: https://phabricator.services.mozilla.com/D44696
--HG--
extra : moz-landing-system : lando
We only have two counters enabled, just for testing, and they just count from
the SVG mapped attribute code. That's not great, and they mostly complicate the
next few patches.
Differential Revision: https://phabricator.services.mozilla.com/D44695
--HG--
extra : moz-landing-system : lando
Adds nsIOSPermissionRequest::MaybeRequestScreenCapturePermission() to allow front-end code to trigger a screen-recording permission request dialog.
Depends on D46093
Differential Revision: https://phabricator.services.mozilla.com/D46094
--HG--
extra : moz-landing-system : lando
Adds nsIOSPermissionRequest::GetScreenCapturePermissionState() to allow front-end code to check if Firefox has already been granted permission to record the screen.
Differential Revision: https://phabricator.services.mozilla.com/D46093
--HG--
extra : moz-landing-system : lando
Now, we can get rid of `TextEditRules` and `HTMLEditRules` completely.
And also this patch renames their cpp files to `TextEditSubActionHandler`
and `HTMLEditSubActionHandler`.
`TextEditor::Init()` and `HTMLEditor::Init()` are still complicated due to
`AutoEditInitRulesTrigger`. The following patch will remove it.
Differential Revision: https://phabricator.services.mozilla.com/D45792
--HG--
rename : editor/libeditor/HTMLEditRules.cpp => editor/libeditor/HTMLEditSubActionHandler.cpp
rename : editor/libeditor/TextEditRules.cpp => editor/libeditor/TextEditSubActionHandler.cpp
extra : moz-landing-system : lando
C'est fini. Now to do the same with the unimplemented ones remains, but it
should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D44698
--HG--
extra : moz-landing-system : lando
By reporting the properties in MappedAttrParser that we used to (the test relies
on counting those), and by adjusting the histogram name to the new thing.
Differential Revision: https://phabricator.services.mozilla.com/D44697
--HG--
extra : moz-landing-system : lando
And add them to the UseCounter enum. Also add some sanity-check assertions that
the reporting code relies on.
This works much like the deprecated operation list.
Differential Revision: https://phabricator.services.mozilla.com/D44696
--HG--
extra : moz-landing-system : lando
We only have two counters enabled, just for testing, and they just count from
the SVG mapped attribute code. That's not great, and they mostly complicate the
next few patches.
Differential Revision: https://phabricator.services.mozilla.com/D44695
--HG--
extra : moz-landing-system : lando
Adds a ServiceWorkerDelegate to GeckoRuntime that allows GeckoView applications
to handle ServiceWorkerClient.openWindow() requests.
Differential Revision: https://phabricator.services.mozilla.com/D45572
--HG--
extra : moz-landing-system : lando
Storing a DocShell rather than a BrowsingContext causes a number of problems
when dealing with cross-process navigations. The most immediate in this case
is that some cross-origin-allowed operations only work after a local-to-remote
navigation only until the original DocShell is destroyed, which causes
intermittent test failures.
It also means, though, that after a local-to-remote navigation, where the
DocShell has not been destroyed, attempts to read same-origin properties still
end up at the old DocShell, and as a result, lie about the current state of
the BrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D46100
MANUAL PUSH: Cannot update re-opened Phabricator revisions.
--HG--
extra : source : 6ba3bcede28a51512b8f17606b917024813e98b9
extra : histedit_source : 8dcc4aaabfc3db541a1269dfcd6414c4009d1c47%2C424b940eac29b4e916ea390223103ca41922375d
Storing a DocShell rather than a BrowsingContext causes a number of problems
when dealing with cross-process navigations. The most immediate in this case
is that some cross-origin-allowed operations only work after a local-to-remote
navigation only until the original DocShell is destroyed, which causes
intermittent test failures.
It also means, though, that after a local-to-remote navigation, where the
DocShell has not been destroyed, attempts to read same-origin properties still
end up at the old DocShell, and as a result, lie about the current state of
the BrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D46100
MANUAL PUSH: Cannot update re-opened Phabricator revisions.
--HG--
extra : rebase_source : 417335868d70932981ae0b8908f60a22bdffb62c
extra : amend_source : 135861c9d33ec4b4d84c2ec36aa407ec91df9130
In places where profiler_is_active() was used around a profiler_add_marker() (or
similar) call, replace it with profiler_can_accept_markers().
Differential Revision: https://phabricator.services.mozilla.com/D44435
--HG--
extra : moz-landing-system : lando
Payloads will serialize themselves into a `BlocksRingBuffer` entry when first
captured.
Later they will be deserialized, to stream JSON for the output profile.
Differential Revision: https://phabricator.services.mozilla.com/D43428
--HG--
extra : moz-landing-system : lando
C'est fini. Now to do the same with the unimplemented ones remains, but it
should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D44698
--HG--
extra : moz-landing-system : lando
By reporting the properties in MappedAttrParser that we used to (the test relies
on counting those), and by adjusting the histogram name to the new thing.
Differential Revision: https://phabricator.services.mozilla.com/D44697
--HG--
extra : moz-landing-system : lando
And add them to the UseCounter enum. Also add some sanity-check assertions that
the reporting code relies on.
This works much like the deprecated operation list.
Differential Revision: https://phabricator.services.mozilla.com/D44696
--HG--
extra : moz-landing-system : lando
We only have two counters enabled, just for testing, and they just count from
the SVG mapped attribute code. That's not great, and they mostly complicate the
next few patches.
Differential Revision: https://phabricator.services.mozilla.com/D44695
--HG--
extra : moz-landing-system : lando
In places where profiler_is_active() was used around a profiler_add_marker() (or
similar) call, replace it with profiler_can_accept_markers().
Differential Revision: https://phabricator.services.mozilla.com/D44435
--HG--
extra : moz-landing-system : lando
Payloads will serialize themselves into a `BlocksRingBuffer` entry when first
captured.
Later they will be deserialized, to stream JSON for the output profile.
Differential Revision: https://phabricator.services.mozilla.com/D43428
--HG--
extra : moz-landing-system : lando
Also removes the UA cache attached to nsILoadGroup and nsIRequestContext and the "http-on-useragent-request" observer notification.
If overriding the user agent is needed "http-on-modify-request" is equally usable (but should be used rarely, for performance reasons). A better way is using nsIDocShell.customUserAgent.
Depends on D14750
Differential Revision: https://phabricator.services.mozilla.com/D14751
--HG--
extra : moz-landing-system : lando
When we call nsContentUtils::IsPatternMatching, we swallow JS engine errors
unconditionally returning true.
This is bad, because if it happens in one of the value sets that arguably
shouldn't change the state of the element, we end up returning an arbitrary
value (true) which may or may not match the previous state of the element.
Handle error explicitly instead, by not updating the state.
Differential Revision: https://phabricator.services.mozilla.com/D45727
--HG--
extra : moz-landing-system : lando
Also removes the UA cache attached to nsILoadGroup and nsIRequestContext and the "http-on-useragent-request" observer notification.
If overriding the user agent is needed "http-on-modify-request" is equally usable (but should be used rarely, for performance reasons). A better way is using nsIDocShell.customUserAgent.
Depends on D14750
Differential Revision: https://phabricator.services.mozilla.com/D14751
--HG--
extra : moz-landing-system : lando
DocumentChannel doesn't use the REDIRECT_INTERNAL flag when replacing itself with a real channel if there has been a real redirect handled in the parent.
This is so that the docshell knows about the URI change, and to add history entries.
The timing data however always wanted to be treated as an internal redirect, so that we don't record a new 'redirectEnd' at the time of the switch.
This adds a new parameter to ConfigureReplacementChannel so that we can more accurately describe the behaviour we need.
Differential Revision: https://phabricator.services.mozilla.com/D45150
--HG--
extra : moz-landing-system : lando
This partially addresses the regression, but not fully. With this patch we don't
maintain shadow trees for nodes that we know won't get rendered.
This works fast in WebKit / Blink because of a bug in their implementation which
doesn't synchronize style attributes, introduced in [1].
You can see this clearly if you click on the bug's test-case and inspect the
<use> shadow trees (there's no style="stroke:orange" whatsoever).
They can kinda get away with it because they don't properly implement SVG 2. In
particular, in Blink / WebKit, the style of the element in the <use> shadow tree
is the style of the referenced element, which means that even if the style
attribute isn't properly synced it's ~ok since it doesn't end up mattering for
styling.
Easiest test-case for the behavior difference is:
```
<!doctype html>
<style>
rect:hover {
fill: green;
}
</style>
<svg width=300 height=300>
<g id="canvas">
<rect fill=red width=100 height=100></rect>
</g>
<g>
<use x=200 href="#canvas"></use>
</g>
</svg>
```
Where Firefox will properly update each square independently when hovered, but
Blink / WebKit won't.
This used to work faster because in this particular test-case we have 3 hidden
<use> elements whose href is the #canvas, which is basically everything.
Before moving to shadow trees we'd do it using anonymous content, and since we
never got a frame we'd never clone the subtree in the first case.
This case was faster before bug 1450250, but this approach makes other cases
slow that were fixed by that bug, like bug 1485402.
So I'll try to optimize shadow tree syncing instead, I guess, but there's no
good reason not to land this in the meantime IMHO.
[1]: f4b022e64b%5E%21/third_party/WebKit/WebCore/svg/SVGElement.cpp
Differential Revision: https://phabricator.services.mozilla.com/D45953
--HG--
extra : moz-landing-system : lando
* The test first asserts that we can actually load iframes in separate subprocesses
* The test now loads in a new tab rather than a new window
* The test no longer uses the "fission" attribute
* The test avoids the BrowsingContext.get pattern, in favour of just passing the
BrowsingContext from one actor to the other directly.
Differential Revision: https://phabricator.services.mozilla.com/D45744
--HG--
extra : moz-landing-system : lando
Also remove the definition of unused struct for tracking of input timestamp.
Depends on D45774
Differential Revision: https://phabricator.services.mozilla.com/D45775
--HG--
extra : moz-landing-system : lando
Note that I've confirmed no-cross-origin-autofocus.html works fine with
enabling fission on w3c-test.org.
Differential Revision: https://phabricator.services.mozilla.com/D44950
--HG--
extra : moz-landing-system : lando
This commit renames nsMathMLElement/nsMathMLElementFactory classes into
MathMLElement/MathMLElementFactory and moves the former into the mozilla::dom
namespace. This is a preliminary step to introduce MathML DOM (bug 1579602).
Code behavior is not changed.
Differential Revision: https://phabricator.services.mozilla.com/D45128
--HG--
rename : dom/mathml/nsMathMLElement.cpp => dom/mathml/MathMLElement.cpp
rename : dom/mathml/nsMathMLElement.h => dom/mathml/MathMLElement.h
rename : dom/mathml/nsMathMLElementFactory.cpp => dom/mathml/MathMLElementFactory.cpp
extra : moz-landing-system : lando
Removes API 19 specifier from test manifests.
There aren't many, but best to clean them up.
Differential Revision: https://phabricator.services.mozilla.com/D45766
--HG--
extra : moz-landing-system : lando
Also removes the UA cache attached to nsILoadGroup and nsIRequestContext and the "http-on-useragent-request" observer notification.
If overriding the user agent is needed "http-on-modify-request" is equally usable (but should be used rarely, for performance reasons). A better way is using nsIDocShell.customUserAgent.
Depends on D14750
Differential Revision: https://phabricator.services.mozilla.com/D14751
--HG--
extra : moz-landing-system : lando
Storing a DocShell rather than a BrowsingContext causes a number of problems
when dealing with cross-process navigations. The most immediate in this case
is that some cross-origin-allowed operations only work after a local-to-remote
navigation only until the original DocShell is destroyed, which causes
intermittent test failures.
It also means, though, that after a local-to-remote navigation, where the
DocShell has not been destroyed, attempts to read same-origin properties still
end up at the old DocShell, and as a result, lie about the current state of
the BrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D46100
--HG--
extra : moz-landing-system : lando
`TextEditRules::DocumentIsEmpty()` is a wrapper of `TextEditor::IsEmpty()` so
that we can get rid of it simply.
`HTMLEditRules::DocumentIsEmpty()` needs to change. It's oddly checks only
`EditorBase::mPaddingBRElementForEmptyEditor` is `nullptr` or not. However,
the editor may be completely empty. And the result may be different from
`TextEditor::IsEmpty()` which is not overridden by `HTMLEditor`. For partially
solving this issue, this patch makes `HTMLEditor` overrides `IsEmpty()` and
optimizes `TextEditor::IsEmpty()`.
With this change, the caller of `HTMLEditRules::DocumentIsEmpty()` may behave
differently in the only caller, `HTMLEditor::SelectEntireDocument()`. And
unfortunately, its root called from `SelectAllCommand::DoCommand()`. However,
it does just collapse `Selection` into the root element (`<body>` or
`Document.documentElement`) if it returns `true`. Therefore, this change
must be safe since anyway `SelectionRefPtr()->SelectAllChildren()` with
the root element is exactly same as `SelectionRefPtr()->Collapse()` with
the empty root element if it's truly empty.
Differential Revision: https://phabricator.services.mozilla.com/D45784
--HG--
extra : moz-landing-system : lando
ServiceWorker mochitests fail for Fission is fixed by bug 1542415.
Remove the skip-if for tests
Differential Revision: https://phabricator.services.mozilla.com/D46030
--HG--
extra : moz-landing-system : lando
PaymentRequestChild could be nullptr while PaymentRequest's owner is nullptr.
Differential Revision: https://phabricator.services.mozilla.com/D46012
--HG--
extra : moz-landing-system : lando
C'est fini. Now to do the same with the unimplemented ones remains, but it
should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D44698
--HG--
extra : moz-landing-system : lando
By reporting the properties in MappedAttrParser that we used to (the test relies
on counting those), and by adjusting the histogram name to the new thing.
Differential Revision: https://phabricator.services.mozilla.com/D44697
--HG--
extra : moz-landing-system : lando
And add them to the UseCounter enum. Also add some sanity-check assertions that
the reporting code relies on.
This works much like the deprecated operation list.
Differential Revision: https://phabricator.services.mozilla.com/D44696
--HG--
extra : moz-landing-system : lando
We only have two counters enabled, just for testing, and they just count from
the SVG mapped attribute code. That's not great, and they mostly complicate the
next few patches.
Differential Revision: https://phabricator.services.mozilla.com/D44695
--HG--
extra : moz-landing-system : lando
To align with the coding style, GetBindingClauseForKeyRange should return its
result rather than by modifying an output parameter.
Differential Revision: https://phabricator.services.mozilla.com/D42853
--HG--
extra : moz-landing-system : lando
Also avoid unnecessary copying of the non-locale-based key in case the locale-based is needed, and reduced code duplication and variable scoping. r=ttung
Differential Revision: https://phabricator.services.mozilla.com/D41404
--HG--
extra : moz-landing-system : lando
Previously, this could be mistaken for the width of the character
sequence.
Differential Revision: https://phabricator.services.mozilla.com/D45522
--HG--
extra : moz-landing-system : lando
We use `NotifyMediaStarted()` and `NotifyMediaStopped()` to notify `MediaControlService` on parent process to start/stop a media controller, and use `NotifyMediaAudibleChanged()` to notify controller's audible state in order to request audio focus.
As our goal is to use media controller to control media element, not for web audio, web speech and other stuffs which also use audio channel agent.
Therefore, we should notify parent process to start/stop controller only for media element, instead of sending a notification in AudioChannelService because that would create media controller for all different consumers which uses audio channel agent.
Differential Revision: https://phabricator.services.mozilla.com/D45591
--HG--
extra : moz-landing-system : lando
Spliting NotifyAudioChannelAgent() to StartAudioChannelAgent() and StopAudioChanelAgent() allows us to start and stop an AudioChannelAgent in a clear naming function, and to do related operation and checking every time we start/stop the agent.
Differential Revision: https://phabricator.services.mozilla.com/D45590
--HG--
extra : moz-landing-system : lando
Note that I've confirmed no-cross-origin-autofocus.html works fine with
enabling fission on w3c-test.org.
Differential Revision: https://phabricator.services.mozilla.com/D44950
--HG--
extra : moz-landing-system : lando
The grammar changes parallel those in https://github.com/heycam/webidl/pull/700
We don't prevent having both a constructor operation and [Constructor] or
[ChromeConstructor], because those extended attributes are about to get
removed, once they are no longer used in our IDL.
Differential Revision: https://phabricator.services.mozilla.com/D45387
--HG--
extra : moz-landing-system : lando
Existing tests will fail when there are more than 1 pending frames when Drain()
is called. Repeatly calling it to ensure all frames will be collected.
Differential Revision: https://phabricator.services.mozilla.com/D43689
--HG--
extra : moz-landing-system : lando
Some existing functions that manipulates H.264 bitstream already cover
most of the efforts for converting Android encoder output. With some minor
changes, they can be called by the encoder to avoid code duplications.
Differential Revision: https://phabricator.services.mozilla.com/D43686
--HG--
extra : moz-landing-system : lando
Accessing `offsetXXX` attributes of element, it would trigger reflow, and sometime it would result in a re-entry of `processCue()` because we would call `processCue()` when `resizecaption` occurs.
One specifical case is that, assigning CSS properties `min-width` and `max-width` at the same video element, in thise case, when we re-enter the `processCues()` and access `offsetXXX`. It seems that the layout system would reprocess those properites again and again and dispatch `resizecaption` when we access `offsetXXX`, which causes an infinite loop, starting from receving `resizecaption`, then calling `processCue()`, accessing `offSetXXX`, triggering reflow, sending `resizecaption` event again.
Therefore, we should stop revisiting `processCues()` if we're already running a processing, we should run a processing once at a time.
Differential Revision: https://phabricator.services.mozilla.com/D45421
--HG--
extra : moz-landing-system : lando
This patch changes a few things about how nsFrameLoader is created, specifically
around the ChangeRemoteness API.
1. The private 'nsFrameLoader::nsFrameLoader' constructor has been simplified to
only have one overload, shared by the different `::Create` static methods.
2. The creation static method used by `ChangeRemoteness` has changed name to
`::Recreate`, as the signature is becoming more like the old method.
3. The `mNetworkCreated` bit is preserved when doing a `ChangeRemoteness`, as a
remoteness change shouldn't be affecting that property.
4. Unused fields are removed from the ChangeRemoteness API.
5. The `remoteType` attribute is now mandatory in the ChangeRemoteness API,
which simplifies the logic and makes it harder to accidentally misuse.
Differential Revision: https://phabricator.services.mozilla.com/D44893
--HG--
extra : moz-landing-system : lando
The (non-normative) window.open spec does not specify what should happen when
window.open is called on a window with a null/discarded browsing context, but
in general the lookup and creation rules do not make sense when the window has
no BC. It does, however, specify that we should return null when a target BC
cannot be found or created, and gives us broad discretion over when we decide
to ignore a load request and return null. Since we can't trigger a
cross-process load from a discarded BC, simply aborting in that case seems
like the logical solution.
For Location objects, the spec is more specific, and requires that we ignore
load attempts on Location objects whose documents are null, which in our
implementation corresponds to a discarded BrowsingContext.
LocationBase::SetURI already enforces this, but a second check in
BrowsingContext::LoadURI is probably a good idea as well.
Differential Revision: https://phabricator.services.mozilla.com/D45635
--HG--
extra : moz-landing-system : lando
Note that the areas are clipped out by all ancestor scroll ports and
their coordinate systems are the screen coordinate. So that we can tell
arbitrary elements in out-of-process iframes are scrolled out or not with
this area and the transform matrix of the iframe on screen coodinate.
Differential Revision: https://phabricator.services.mozilla.com/D44420
--HG--
extra : moz-landing-system : lando
We are going to use these functions in gfx/layers/apz/tests/mochitest/ for
fission.
Differential Revision: https://phabricator.services.mozilla.com/D44418
--HG--
extra : moz-landing-system : lando
In most of the cases, the value to be stored is the same as the existing value, which does not require an update to the database. Setting something in the database requires disk access. By using this we avoid accessing the disk in the majority of the cases.
Differential Revision: https://phabricator.services.mozilla.com/D45504
--HG--
extra : moz-landing-system : lando
Existing tests will fail when there are more than 1 pending frames when Drain()
is called. Repeatly calling it to ensure all frames will be collected.
Differential Revision: https://phabricator.services.mozilla.com/D43689
--HG--
extra : moz-landing-system : lando
Some existing functions that manipulates H.264 bitstream already cover
most of the efforts for converting Android encoder output. With some minor
changes, they can be called by the encoder to avoid code duplications.
Differential Revision: https://phabricator.services.mozilla.com/D43686
--HG--
extra : moz-landing-system : lando
The principals used in worklet scripts derive from the relevant settings object
of the main thread Worklet object, rather than the network loads of the scripts.
Moving the data off LoadInfo removes any implication that the principals might
depend on script module loads.
Differential Revision: https://phabricator.services.mozilla.com/D44775
--HG--
extra : moz-landing-system : lando
DecoderDoctorDiagnostics had no limitations on reported and stored issues.
New limitations, per document:
- No more than 128 issues are kept at any time.
- Issues older than 10 seconds are discarded.
- Issues containing too-long text (more than 2048 characters) are ignored.
Differential Revision: https://phabricator.services.mozilla.com/D45480
--HG--
extra : moz-landing-system : lando
Right now, we end up with the forward declaration of
nsIDOMWindowProxy, which does not exist, instead of the proper type.
Differential Revision: https://phabricator.services.mozilla.com/D45516
--HG--
extra : moz-landing-system : lando
Setting prefs in test does not have effect to top level document. We
should move the prefs to default part of ini file
Differential Revision: https://phabricator.services.mozilla.com/D45509
--HG--
extra : moz-landing-system : lando
Harmonized and provided a rationale for defining statement parameter names literally vs. by named constant,
and referencing them in binding calls by index vs. by name.
Differential Revision: https://phabricator.services.mozilla.com/D41026
--HG--
extra : moz-landing-system : lando
Harmonized and provided a rationale for defining statement parameter names literally vs. by named constant,
and referencing them in binding calls by index vs. by name.
Differential Revision: https://phabricator.services.mozilla.com/D41026
--HG--
extra : moz-landing-system : lando
The wpt will be updated in
https://github.com/web-platform-tests/wpt/pull/18866.
Besides, there are some other test cases use text-decoration, so we
have to update them as well. The rule is: if the test case is not related to
old `text-decoration` longhand, we use `text-decoration-line` instead.
If the test case is for testing the change of `text-decoration` from
longhand to shorthand, we should use the correct serialization.
Differential Revision: https://phabricator.services.mozilla.com/D44909
--HG--
extra : moz-landing-system : lando
When GetDocumentLoadGroup returns a null load group, we should create a new one.
Differential Revision: https://phabricator.services.mozilla.com/D44831
--HG--
extra : moz-landing-system : lando
The only reason dom/system/tests/test_bug1197901.html doesn't fail right now
when Fission is enabled is because the test is racy since the 'load' event
doesn't wait for OOP iframes. As a result the test finishes "testing" the
OOP-iframe before the OOP-iframe has even loaded.
Differential Revision: https://phabricator.services.mozilla.com/D45211
--HG--
extra : moz-landing-system : lando
The CommonCreateWindow code requires having a BrowserHost for the tab that's
creating the window, which it tries to get from the requestor's BrowserParent.
For remote BrowserParents, though, there is no BrowserHost, so we need to get
it from the top-level embedder instead.
Differential Revision: https://phabricator.services.mozilla.com/D45172
--HG--
extra : moz-landing-system : lando
The problem reproduces when the system is loaded and the decoder is dropping most of the frames. When there are two benchmark calculations close to each other, the measured parsed frames of the first calculation can be buffered in the decoder and reported as dropped frames on the second calculation. Then on the second calculation, the number of dropped frames can be greater than the parsed frame which will hit the assert. The number of total frames is a better measure since it counts the frames that appeared in the in VideoSink plus the total dropped frames.
Differential Revision: https://phabricator.services.mozilla.com/D44478
--HG--
extra : moz-landing-system : lando
dom.security.featurePolicy.enabled is enable only in nightly, so some
tests in beta will be failed. We should manually enable the pref in test.
Differential Revision: https://phabricator.services.mozilla.com/D44990
--HG--
extra : moz-landing-system : lando
When we initially create a FrameLoader for a new tab created by a
window.open() call or a link click, it automatically winds up in the correct
tab group, because it's created in the child.
The problem comes when the window navigates to a new origin which requires a
process switch, and then navigates back to the same origin as its opener (for
instance, using `history.back()`). In that case, the parent rebuilds the frame
loader in a new tab group. But, since the child knows that it has an opener,
and that opener is in the same process, it (rightly) expects it to be in the
same tab group as its opener, and puts it there. It then asserts that this
matches the tab group of its actor, and explodes.
This patch fixes that, so that the parent checks whether its BrowsingContext
has an opener, and if does, tells the child to join its tab group.
Differential Revision: https://phabricator.services.mozilla.com/D44737
--HG--
extra : moz-landing-system : lando
The principals used in worklet scripts derive from the relevant settings object
of the main thread Worklet object, rather than the network loads of the scripts.
Moving the data off LoadInfo removes any implication that the principals might
depend on script module loads.
Differential Revision: https://phabricator.services.mozilla.com/D44775
--HG--
extra : moz-landing-system : lando
The test originally assumed that the BrowsingContext for the crashing
frame would get destroyed and replaced with a new one. Having read through
some of bug 1563619 though, it looks as if we preserve the BrowsingContext
after the subframe crashes, so I've modified the test to skip that check.
It also looks like we have to wait until the WindowGlobalParent is created
asynchronously from the about:blank load that's initiated in the content
process before we can query the subframe for its current location, so
I've added a waitForCondition for that.
Differential Revision: https://phabricator.services.mozilla.com/D43814
--HG--
extra : moz-landing-system : lando
PresentScreenBuffer() or screen->PublishFrame() may fail for different reasons. In that case we shouldn't call surface->Commit() because it may be in a not swaped state or not available.
Differential Revision: https://phabricator.services.mozilla.com/D44813
--HG--
extra : moz-landing-system : lando
The test originally assumed that the BrowsingContext for the crashing
frame would get destroyed and replaced with a new one. Having read through
some of bug 1563619 though, it looks as if we preserve the BrowsingContext
after the subframe crashes, so I've modified the test to skip that check.
It also looks like we have to wait until the WindowGlobalParent is created
asynchronously from the about:blank load that's initiated in the content
process before we can query the subframe for its current location, so
I've added a waitForCondition for that.
Differential Revision: https://phabricator.services.mozilla.com/D43814
--HG--
extra : moz-landing-system : lando
The session restore page keeps its restore list within a text input field
so that the values are persisted even if the page is refreshed. When form
elements were loaded with the prototype cache we didn't call
DoneCreatingElement after creating the element, which means the form values
weren't restored.
The list of elements that require DoneCreatingElement and DoneAddingChildren
to be called was in three (now four) different places, so I moved them to
a central spot in nsIContent to share in all locations. This also highlighted
that the check for <output> nodes is missing from the XML content sink.
Differential Revision: https://phabricator.services.mozilla.com/D44866
--HG--
extra : moz-landing-system : lando
Dealing with a case where `DecodeNALUnit()` returns nullptr which we should not try to create bit reader and decode anything.
In addition, wrap these logic to `DecodedISlice()` in order to keep consistent with a case where we decode SEI.
Differential Revision: https://phabricator.services.mozilla.com/D44875
--HG--
extra : moz-landing-system : lando
This patch converts NoInterfaceObject interfaces GlobalEventHandlers and
DocumentAndElementEventHandlers to mixins and introduce a new
ElementCSSInlineStyle mixin for the style IDL attribute. These are shared by
various existing interfaces but there is no web-exposed behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D45029
--HG--
extra : moz-landing-system : lando
Clearkey previously relied on OpenAES to do its encryption. In order to
facilitate future changes and the need for CBC support, switch to NSS, which
should be more flexible and actively maintained.
Differential Revision: https://phabricator.services.mozilla.com/D41993
--HG--
extra : moz-landing-system : lando
The session restore page keeps its restore list within a text input field
so that the values are persisted even if the page is refreshed. When form
elements were loaded with the prototype cache we didn't call
DoneCreatingElement after creating the element, which means the form values
weren't restored.
The list of elements that require DoneCreatingElement and DoneAddingChildren
to be called was in three (now four) different places, so I moved them to
a central spot in nsIContent to share in all locations. This also highlighted
that the check for <output> nodes is missing from the XML content sink.
Differential Revision: https://phabricator.services.mozilla.com/D44866
--HG--
extra : moz-landing-system : lando
Most of our keyboard shortcut handling is handled by nsXBLWindowKeyHandler along
with nsXBLPrototypeHandler. With the impending removal of XBL this needs to
change.
This patch moves nsXBLWindowKeyHandler to dom/events/GlobalKeyListener and copies
nsXBLPrototypeHandler to dom/events/KeyEventHandler. Windows, text elements and
XUL <keyset> are changed to use the new copies and anything unnecessary for
those is stripped out.
XBL handler elements still remain using the existing nsXBLPrototypeHandler path.
Some of the code is ripped out there to make it compile. There is probably a
lot more that can be removed but since the whole of XBL is likely gone soon I'm
not sure it is worth cleaning that up much.
Differential Revision: https://phabricator.services.mozilla.com/D42336
--HG--
rename : dom/xbl/nsXBLWindowKeyHandler.cpp => dom/events/GlobalKeyListener.cpp
rename : dom/xbl/nsXBLWindowKeyHandler.h => dom/events/GlobalKeyListener.h
rename : dom/xbl/nsXBLPrototypeHandler.cpp => dom/events/KeyEventHandler.cpp
rename : dom/xbl/nsXBLPrototypeHandler.h => dom/events/KeyEventHandler.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForBrowserCommon.h => dom/events/ShortcutKeyDefinitionsForBrowserCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForEditorCommon.h => dom/events/ShortcutKeyDefinitionsForEditorCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForInputCommon.h => dom/events/ShortcutKeyDefinitionsForInputCommon.h
rename : dom/xbl/builtin/ShortcutKeyDefinitionsForInputCommon.h => dom/events/ShortcutKeyDefinitionsForTextAreaCommon.h
rename : dom/xbl/builtin/ShortcutKeys.cpp => dom/events/ShortcutKeys.cpp
rename : dom/xbl/builtin/ShortcutKeys.h => dom/events/ShortcutKeys.h
rename : dom/xbl/builtin/android/ShortcutKeyDefinitions.cpp => dom/events/android/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/android/moz.build
rename : dom/xbl/builtin/emacs/ShortcutKeyDefinitions.cpp => dom/events/emacs/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/emacs/moz.build
rename : dom/xbl/builtin/mac/ShortcutKeyDefinitions.cpp => dom/events/mac/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/mac/moz.build
rename : dom/xbl/builtin/unix/ShortcutKeyDefinitions.cpp => dom/events/unix/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/unix/moz.build
rename : dom/xbl/builtin/win/ShortcutKeyDefinitions.cpp => dom/events/win/ShortcutKeyDefinitions.cpp
rename : dom/xbl/builtin/android/moz.build => dom/events/win/moz.build
extra : moz-landing-system : lando
Remove test manifest annotations that specifically target fennec,
or likely target the android 4.3 emulator.
Differential Revision: https://phabricator.services.mozilla.com/D45018
--HG--
extra : moz-landing-system : lando