Add encryption scheme member to MediaKeySystemMediaCapability dict, but hide it
behind a pref as the behaviour involved is only proposed at this stage.
Differential Revision: https://phabricator.services.mozilla.com/D34301
--HG--
extra : moz-landing-system : lando
Also, in many place, we use document uri as referrer. It is not right
for the case srdoc iframe. We should use the last non-srdoc parent
document's uri
Differential Revision: https://phabricator.services.mozilla.com/D30191
--HG--
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-data.html
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-srcdoc.html
extra : moz-landing-system : lando
This is similar to this Chromium change:
https://codereview.chromium.org/1155353002
The editing spec doesn't mention editing non-HTML documents, and historically
this is only a feature that WebKit has supported. Supporting this feature
increases the attack surface of the browser without a clear benefit, so it
seems like a good idea to converge on this behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D32913
--HG--
rename : testing/web-platform/tests/html/editing/editing-0/making-entire-documents-editable-the-designmode-idl-attribute/user-interaction-editing-designMode.html => testing/web-platform/tests/html/editing/editing-0/making-entire-documents-editable-the-designmode-idl-attribute/user-interaction-editing-designMode-xml.xml
extra : moz-landing-system : lando
This patch structurizes the media debug information via webidl dictionaries
that are returned by HTMLMediaElement::GetMozRequestDebugInfo() and
MediaSource::GetMozDebugReaderData().
Differential Revision: https://phabricator.services.mozilla.com/D27893
--HG--
extra : moz-landing-system : lando
There are two related problems this patch is trying to address. The first, and
simpler, one is bug 1553436: there are websites that use existing variables and
functions named "u2f" and adding a non-replaceable readonly property with that
name on Window breaks them. The fix for this is straightforward: mark the
property [Replaceable].
The second problem, covered by bug 1551282, involves sites that use the Google
U2F polyfill. The relevant parts of that polyfill look like this:
'use strict';
var u2f = u2f || {};
u2f.register = some_function_that_only_works_right_in_Chrome;
u2f.sign = some_function_that_only_works_right_in_Chrome;
The failure mode for that code before this fix is that the assignment to "u2f"
throws because it's a readonly property and we're in strict mode, so any code
the page concatenates in the same file after the polyfill does not get run.
That's what bug 1551282 is about. The [Replaceable] annotation fixes that
issue, because now the polyfill gets the value of window.u2f and then redefines
the property (via the [Replaceable] setter) to be a value property with that
value. So far, so good.
But then we need to prevent the sets of u2f.register
and u2f.sign from taking effect, because if they are allowed to happen, the
actual sign/register functionality on the page will not work in Firefox. We
can't just make the properties readonly, because then the sets will throw due
to being in strict mode, and we still have bug 1551282. The proposed fix is to
make these accessor properties with a no-op setter, which is exactly what
[LenientSetter] gives us.
The rest of the patch is just setting up infrastructure for generating the
normal bits we would generate if "sign" and "register" were methods and using
that to create the JSFunctions at the point when the getter is called. The
JSFunctions then get cached on the u2f instance object.
Differential Revision: https://phabricator.services.mozilla.com/D32357
--HG--
extra : moz-landing-system : lando
There are two related problems this patch is trying to address. The first, and
simpler, one is bug 1553436: there are websites that use existing variables and
functions named "u2f" and adding a non-replaceable readonly property with that
name on Window breaks them. The fix for this is straightforward: mark the
property [Replaceable].
The second problem, covered by bug 1551282, involves sites that use the Google
U2F polyfill. The relevant parts of that polyfill look like this:
'use strict';
var u2f = u2f || {};
u2f.register = some_function_that_only_works_right_in_Chrome;
u2f.sign = some_function_that_only_works_right_in_Chrome;
The failure mode for that code before this fix is that the assignment to "u2f"
throws because it's a readonly property and we're in strict mode, so any code
the page concatenates in the same file after the polyfill does not get run.
That's what bug 1551282 is about. The [Replaceable] annotation fixes that
issue, because now the polyfill gets the value of window.u2f and then redefines
the property (via the [Replaceable] setter) to be a value property with that
value. So far, so good.
But then we need to prevent the sets of u2f.register
and u2f.sign from taking effect, because if they are allowed to happen, the
actual sign/register functionality on the page will not work in Firefox. We
can't just make the properties readonly, because then the sets will throw due
to being in strict mode, and we still have bug 1551282. The proposed fix is to
make these accessor properties with a no-op setter, which is exactly what
[LenientSetter] gives us.
The rest of the patch is just setting up infrastructure for generating the
normal bits we would generate if "sign" and "register" were methods and using
that to create the JSFunctions at the point when the getter is called. The
JSFunctions then get cached on the u2f instance object.
Differential Revision: https://phabricator.services.mozilla.com/D32357
--HG--
extra : moz-landing-system : lando
If we're doing a process switch due to the cross origin opener policy
being mismatched, we don't want to preserve the browsing context.
Differential Revision: https://phabricator.services.mozilla.com/D26392
If we're doing a process switch due to the cross origin opener policy
being mismatched, we don't want to preserve the browsing context.
Differential Revision: https://phabricator.services.mozilla.com/D26392
According to the spec [1] 7.2.10.2, we should use the first line box's height or width as positioning unit to adjust box's position.
We will also use this value to adjust box when `snap-to-line` is false.
There, we implement a new chrome-only API to acquire this information, which would return the first line box's size in the `block` frame.
[1] https://www.w3.org/TR/webvtt1/#ref-for-webvtt-cue-snap-to-lines-flag-12
Differential Revision: https://phabricator.services.mozilla.com/D29745
--HG--
extra : moz-landing-system : lando
When adjusting cue's position, the goal is to place cue boxes fully inside the rendering area, and place in the right place.
In order to check whether the box is correctly inside the rendering area, we have to know the correct size of the cue box.
Therefore, we implement the new chrome-only APIs to acquire this information (box's height and width), and this returned value won't be affected by CSS transformation, which is good for positioning.
Differential Revision: https://phabricator.services.mozilla.com/D27178
--HG--
extra : moz-landing-system : lando
It's not worth dying on this hill. Both Blink and WebKit pass the tests.
(Well, WebKit actually fails one of the latest ones I wrote, cssRules and rules
are not the same JS object, WebKit returns a new rule list. I'll file)
Spec PR in https://github.com/w3c/csswg-drafts/pull/3900.
Differential Revision: https://phabricator.services.mozilla.com/D30348
--HG--
extra : moz-landing-system : lando
In this patch, we support
1. content-box (default)
2. border-box
And let ResizeObserverEntry expose these box sizes.
Besides, we store the mLastReportedSize as the logical size.
Differential Revision: https://phabricator.services.mozilla.com/D28737
--HG--
extra : moz-landing-system : lando
This patch structurizes the media debug information via webidl dictionaries
that are returned by HTMLMediaElement::GetMozRequestDebugInfo() and
MediaSource::GetMozDebugReaderData().
Differential Revision: https://phabricator.services.mozilla.com/D27893
--HG--
extra : moz-landing-system : lando
This also adds an isTopFrame attribute to the FrameCrashedEvent binding, which
returns true if the frame that crashed was the top-most one.
Differential Revision: https://phabricator.services.mozilla.com/D29236
--HG--
extra : moz-landing-system : lando
This patch adds an ID to ensure that we avoid canceling content JS if the next
page already started loading by the time we're ready to try canceling the JS.
Differential Revision: https://phabricator.services.mozilla.com/D25164
--HG--
extra : moz-landing-system : lando
In this part, we pass along the navigation type (and index for when using the
dropdown on the back/forward buttons). This allows us to check if there's a
top-level load "between" the start and end pages.
The patch might look a bit strange, since we're passing the navigation
operation to two places from RemoteWebNavigation.js (the normal message passing
that existed before this patch and the HangMonitor channel in this patch). This
is primarily to make it easier to stop passing the navigation info along the
HangMonitor channel once session history is uplifted into the parent process.
At that point, the check for whether there's a top-level load could happen in
TabParent (I think).
Differential Revision: https://phabricator.services.mozilla.com/D23090
--HG--
extra : moz-landing-system : lando
This implements the first version of spec, so the webidl file doesn't
match the current spec and we will fix them in the follow-up bugs.
i.e.
1. The default observer box is content-box.
2. `ResizeObserverBoxOptions`, `ResizeObserverOptions`, and `ResizeObserverSize`
are not included in `ResizeObserver.webidl`.
3. `ResizeObserverEntry` doesn't have `borderBoxSize` and `contentBoxSize`
attributes.
Depends on D27615
Differential Revision: https://phabricator.services.mozilla.com/D27616
--HG--
extra : moz-landing-system : lando
This implements the first version of spec, so the webidl file doesn't
match the current spec and we will fix them in the follow-up bugs.
i.e.
1. The default observer box is content-box.
2. `ResizeObserverBoxOptions`, `ResizeObserverOptions`, and `ResizeObserverSize`
are not included in `ResizeObserver.webidl`.
3. `ResizeObserverEntry` doesn't have `borderBoxSize` and `contentBoxSize`
attributes.
Depends on D27615
Differential Revision: https://phabricator.services.mozilla.com/D27616
--HG--
extra : moz-landing-system : lando
the requestSecurityCode allows merchants to opt out of requiring a CVV from a credit card.
Differential Revision: https://phabricator.services.mozilla.com/D28777
--HG--
extra : moz-landing-system : lando
nsITabParent is exposed to frontend code and is generally used as a representation of a remote tab. We could just rename the interface to nsIBrowserParent and worry about it later, but I think it's better to rename the interface to nsIRemoteTab so that we can later work on splitting the interface away from the PBrowser protocol.
Note: Some frontend code refers to a TabParentId. This commit renames this to RemoteTabId. We need to figure out the purpose of TabId with fission.
Differential Revision: https://phabricator.services.mozilla.com/D28132
--HG--
rename : dom/interfaces/base/nsITabParent.idl => dom/interfaces/base/nsIRemoteTab.idl
extra : rebase_source : 9d8a1790a7bb10195ad063644d1a93d63b2afb72
This patch adds an ID to ensure that we avoid canceling content JS if the next
page already started loading by the time we're ready to try canceling the JS.
Differential Revision: https://phabricator.services.mozilla.com/D25164
--HG--
extra : moz-landing-system : lando
In this part, we pass along the navigation type (and index for when using the
dropdown on the back/forward buttons). This allows us to check if there's a
top-level load "between" the start and end pages.
The patch might look a bit strange, since we're passing the navigation
operation to two places from RemoteWebNavigation.js (the normal message passing
that existed before this patch and the HangMonitor channel in this patch). This
is primarily to make it easier to stop passing the navigation info along the
HangMonitor channel once session history is uplifted into the parent process.
At that point, the check for whether there's a top-level load could happen in
TabParent (I think).
Differential Revision: https://phabricator.services.mozilla.com/D23090
--HG--
extra : moz-landing-system : lando
...instead of forwarding to the sheet like HTMLStyleElement does.
I've proposed this behavior in:
https://github.com/whatwg/html/issues/3840#issuecomment-480894419
I think this is one of the sane behaviors we can have, what Blink / WebKit do
makes no sense to me.
Alternative potentially-sane behavior is making the initial value of the
stylesheet's disabled bit the same as the content attribute, and both reflect
and forward the attribute from the setter.
That means that setAttribute does something different than setting `disabled`,
which means that you can get into all sorts of funny states when reloading the
sheet... So I rather not do that.
Differential Revision: https://phabricator.services.mozilla.com/D26573
--HG--
extra : moz-landing-system : lando
...instead of forwarding to the sheet like HTMLStyleElement does.
I've proposed this behavior in:
https://github.com/whatwg/html/issues/3840#issuecomment-480894419
I think this is one of the sane behaviors we can have, what Blink / WebKit do
makes no sense to me.
Alternative potentially-sane behavior is making the initial value of the
stylesheet's disabled bit the same as the content attribute, and both reflect
and forward the attribute from the setter.
That means that setAttribute does something different than setting `disabled`,
which means that you can get into all sorts of funny states when reloading the
sheet... So I rather not do that.
Differential Revision: https://phabricator.services.mozilla.com/D26573
--HG--
extra : moz-landing-system : lando
This adds a codepath to the process switching logic to, rather than triggering
a fresh load, resume a process switching load.
Differential Revision: https://phabricator.services.mozilla.com/D27512
--HG--
extra : moz-landing-system : lando
- Remove expectation that 'preventScroll.html' fails.
- Use '[NoInterfaceObject] interface' workaround to simulate missing 'mixin' support.
Differential Revision: https://phabricator.services.mozilla.com/D26922
--HG--
extra : moz-landing-system : lando
This patch extracts two additional CompositorHitTestInfo flags from the
eDispatchToContent flag; eApzAwareListeners for elements that have
APZ-aware listeners, and eInactiveScrollframe for inactive scrollframe
or unlayerized scrollthumbs. The eDispatchToContent is then renamed to
eIrregularArea to reflect the fact that it is used for irregular-shaped
areas that require main-thread hit-testing.
Additionally, it is important to note that when using the non-WebRender
codepath, all three of these flags still end up gettings squashed into
the "dispatch to content" region on the EventRegions; when APZ
reconstructs a CompositorHitTestInfo it will turn anything in this
region back into an eIrregularArea. So this is a lossy round-trip
conversion for the non-WebRender case. However it should still result in
correct behaviour because the semantics of eIrregularArea result in APZ
relying on the main-thread to do hit-testing and so any APZ-aware
listeners and inactive scrollframes are also handled by the main-thread.
Differential Revision: https://phabricator.services.mozilla.com/D26440
--HG--
extra : moz-landing-system : lando
The img decode API allows a web author to request that an image be
decoded at its intrinsic size and be notified when it has been
completed. This is useful to ensure an image is ready to display before
adding it to the DOM tree -- this will help reduce flickering.
Differential Revision: https://phabricator.services.mozilla.com/D11362
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
--HG--
extra : moz-landing-system : lando
If user disables clipboard events, it means that they don't want to expose
clipboard data to web apps even if web apps cannot handle "paste" operation.
Therefore, they must not want to leak clipboard data with `InputEvent.data`
and `InputEvent.dataTransfer`.
This patch makes `InputEvent::GetData()` and `InputEvent::GetDataTransfer()`
returns empty string or new `DataTransfer` object which has only empty string
if:
- They are called by content JS.
- The event is a trusted event.
- `inputType` value is `insertFromPaste` or `insertFromPasteAsQuotation`.
The reason why we don't return null for both is, Input Events spec declares
`data` or `dataTransfer` shouldn't be null in the `inputType` values. And
the reason why we don't return empty `DataTransfer` is, web apps may expect
at least one data is stored in non-null `dataTransfer` value.
Differential Revision: https://phabricator.services.mozilla.com/D25350
--HG--
extra : moz-landing-system : lando
This removes all the unimplemented RTCStats types from RTCStatsReport.webidl and deletes the related code
Differential Revision: https://phabricator.services.mozilla.com/D23276
--HG--
extra : moz-landing-system : lando
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
--HG--
extra : moz-landing-system : lando
realigning the RTP stats types to match spec. This involves breaking out the remote dictionary types. This shouldn't create user space visible changes.
Differential Revision: https://phabricator.services.mozilla.com/D20432
--HG--
extra : moz-landing-system : lando
nsIDOMGetUserMediaErrorCallback, nsIDOMGetUserMediaSuccessCallback,
and nsIGetUserMediaDevicesSuccessCallback were completely unused, so
they could just go away and all the code got simpler.
Differential Revision: https://phabricator.services.mozilla.com/D23782
--HG--
extra : moz-landing-system : lando
I'm a bit torn between the const-member-and-MOZ_KnownLive approach
here and just taking extra stack refs...
Differential Revision: https://phabricator.services.mozilla.com/D23778
--HG--
extra : moz-landing-system : lando
We add a [MOZ_CAN_RUN_SCRIPT_BOUNDARY] opt-out for now to keep the tree
compiling. The naming purposefully matches the C++ annotation that has a
similar effect, top make it easy to search for.
Differential Revision: https://phabricator.services.mozilla.com/D23520
--HG--
extra : moz-landing-system : lando
Looks like these three APIs slipped through when shipping v1, but no other
vendor supports them, so no reason to be here.
I don't think there's any harm in letting the implementations keep living in
DocumentOrShadowRoot, but let me know if you think otherwise and I'll move them
to Document.
Differential Revision: https://phabricator.services.mozilla.com/D23577
--HG--
extra : moz-landing-system : lando
Adds a method for to nsFrameLoaderOwner destroying and rebuilding a
FrameLoader in order to facilitate a process switch. Method works
without requiring that the work be done in the frontend.
Depends on D22789
Differential Revision: https://phabricator.services.mozilla.com/D22790
--HG--
extra : moz-landing-system : lando
Hiding document.createEvent("TouchEvent"), document.createTouch, document.createTouchList and ontouch* event
handlers on desktop to follow what Chrome has done.
This patch explicitly does not remove createTouch or createTouchList everywhere, although those seem to have been
removing already on some other browsers.
Devtools use TOUCHEVENTS_OVERRIDE_ENABLED for touch event testing, and this patch keeps the old behavior per discussion
with devtools devs.
Differential Revision: https://phabricator.services.mozilla.com/D22081
--HG--
extra : rebase_source : 562588a289632ba2f11db7f3ac8782c26c3b05f8
InputEvent.dataTransfer is declared by Input Events Level 1 and Level 2 (i.e.,
not UI Events). It's necessary for "beforeinput" event on contenteditable
elements because of with some InputEvent.inputType values on contenteditable,
InputEvent.dataTransfer is used instead of InputEvent.data.
According to the Chrome's behavior, if InputEvent.dataTransfer is created by
web apps, the DataTransfer object is mutable. Otherwise, i.e., the event
represents user input, the DataTransfer object is read only. We should follow
this behavior.
This is enabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D19296
--HG--
extra : moz-landing-system : lando
InputEvent.data notifies web apps of inserting/inserted text with "beforeinput"
and "input" events. So, this is important especially for "beforeinput" event
listeners. That's the reason why we need to support this before implementing
"beforeinput" event.
This patch adds it into InputEvent and make it enabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D19285
--HG--
extra : moz-landing-system : lando
We support CTAP2 devices on one specific platform, making it hard for RPs to
decide whether or not Firefox will support the tokens they're asking for. This
adds a non-standard method to divine that information while Firefox moves toward
CTAP2 support.
Differential Revision: https://phabricator.services.mozilla.com/D19826
--HG--
extra : moz-landing-system : lando
Changing the units roundTripTime is reported in from milliseconds to seconds
Differential Revision: https://phabricator.services.mozilla.com/D19544
--HG--
extra : moz-landing-system : lando
The class contains original full referrer and referrer policy will be
applied to the referrer.
Differential Revision: https://phabricator.services.mozilla.com/D17923
--HG--
extra : moz-landing-system : lando
We haven't supported addons that require restarts in some time
and a bunch of the underlying support for this flag is already gone
from the addons manager. The mozAddonManager api is one of the
last vestiges, this patch rips it out.
Differential Revision: https://phabricator.services.mozilla.com/D18745
--HG--
extra : moz-landing-system : lando
Old Confluence does not aware of conflated model keypress event (see UI Events
spec, https://w3c.github.io/uievents/#determine-keypress-keyCode).
Additionally, Confluence can be hosted with any domains. Therefore, we cannot
use blacklist to disable the conflated model keypress event only on it.
This patch checks whether current or parent document is Confluence with JS
module, called KeyPressEventModelCheckerChild. For kicking this module,
nsHTMLDocument dispatches an custom event, CheckKeyPressEventModel, when it
becomes editable only first time. Finally, if it's a Confluence instance, the
module let PresShell know that we need to use split model keypress event in it.
Differential Revision: https://phabricator.services.mozilla.com/D17907
--HG--
extra : moz-landing-system : lando
This patch removes the XBL marquee binding and always uses
UA Widget for the internal "gut" of the marquee element.
Depends on D17572
Differential Revision: https://phabricator.services.mozilla.com/D17573
--HG--
extra : moz-landing-system : lando
When user middle clicks a link, most users must not expect to expose clipboard
content to the web application. Therefore, we should stop firing paste event
when user click a link with middle button.
This patch makes ClickHandlerChild.handleEvent() prevent multiple action
when it posts middle click event on a link. Note that even if middle click
event is consumed, default event handler will dispatch paste event.
Unfortunately, this is compatible behavior with the other browsers.
Therefore, we cannot change this behavior with calling preventDefault() and
this is the reason why this patch adds Event.preventMultipleActions().
Out of scope of this bug though, if there is an element which looks like a
link but implemented with JS, web apps can steal clipboard content if user
enables middle click event and user just wants to open the link in new tab.
It might be better to stop dispatching paste event in any browsers and request
to change each web apps.
Differential Revision: https://phabricator.services.mozilla.com/D17209
--HG--
extra : moz-landing-system : lando
We can just check for a non-global object (so excluding Window) with cross-origin properties.
Differential Revision: https://phabricator.services.mozilla.com/D15430
--HG--
extra : moz-landing-system : lando
The restriction preventing fullscreen windows from being dragged is removed.
Differential Revision: https://phabricator.services.mozilla.com/D15075
--HG--
extra : moz-landing-system : lando
The restriction preventing fullscreen windows from being dragged is removed.
Differential Revision: https://phabricator.services.mozilla.com/D15075
--HG--
extra : moz-landing-system : lando
They are needed so the chrome script (CastingApp.js) can read back the state
of the video element.
Differential Revision: https://phabricator.services.mozilla.com/D16489
--HG--
extra : moz-landing-system : lando
`document.autoplayPolicy` returns a enum string that can change overtime based on user session activity:
- “allowed” if autoplay is currently allowed.
- “allowed-muted” if muted video autoplay is currently allowed.
- “disallowed” is autoplay is not current allowed.
Differential Revision: https://phabricator.services.mozilla.com/D11543
--HG--
extra : moz-landing-system : lando
This allows us to centralize the logic about which field names are "sensitive" and shouldn't be saved in things like form history or session history.
Differential Revision: https://phabricator.services.mozilla.com/D16128
--HG--
extra : moz-landing-system : lando
This patch implements InputType.inputType which is declared by Input Events.
The attribute has already been implemented by Chrome and Safari. Chrome
implements Input Events Level 1, but Safari implements Input Events Level 2.
Difference between them is only whether it supports "insertFromComposition",
"deleteByComposition" and "deleteCompositionText". This patch makes the
level switchable with pref and takes Level 1 by default because Level 2 is
still unstable around event order with composition events.
For reducing string copy cost at dispatching "input" event, this patch
makes EditorInternalInputEvent store valid input-type as enum class,
EditorInputType and resolves it to string value when
dom::InputEvent::GetInputType() is called. Note that the reason why
this patch names the enum class as EditorInputType is, there is InputType
enum class already for avoiding conflict the name, this appends "Editor"
prefix because "input" and "beforeinput" events are fired only when an
editor has focus.
Differential Revision: https://phabricator.services.mozilla.com/D14128
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
Cache whether an input was ever type=password so consumers can handle sites which toggle password visibility and don't want to save the value of the field.
Differential Revision: https://phabricator.services.mozilla.com/D15145
--HG--
extra : moz-landing-system : lando
Removes RTP stat field isRemote and adds the new types remote-inbound-rtp, and remote-outbound-rtp
Differential Revision: https://phabricator.services.mozilla.com/D15068
--HG--
extra : moz-landing-system : lando
Removes RTP stat field isRemote and adds the new types remote-inbound-rtp, and remote-outbound-rtp
Differential Revision: https://phabricator.services.mozilla.com/D15068
--HG--
extra : moz-landing-system : lando
The pref dom.chrome_frame_access.enabled will default to true. When false, it will block various methods that chrome code can use to traverse subframes. The initial list is:
iframe.contentWindow
iframe.contentDocument
window.top
window.parent
window.opener
window.frames[i]
window.frames.length
MessageEvent.source
More blocks are likely to be added in the future.
Differential Revision: https://phabricator.services.mozilla.com/D13180
--HG--
extra : moz-landing-system : lando
These are undocumented and were only used for the about:webrtc page. They can
be removed without first deprecating them.
Differential Revision: https://phabricator.services.mozilla.com/D14464
--HG--
extra : moz-landing-system : lando
This should make BrowsingContext more usable by making it much easier to obtain
for a given frame or browser. BrowsingContext and nsFrameLoader should have
the same lifetime.
Differential Revision: https://phabricator.services.mozilla.com/D9395
There's now an upper limit for snapshot prefilling. The value is configurable and is currently set to 4096 bytes.
Snapshots can operate in multiple modes depending on if all items have been loaded or all keys have been received. This should provide the best performance for each specific state.
This patch also adds support for creating explicit snapshots which can be used for testing.
New methods open() and close() are added to the Storage WebIDL interface. They are only available when a pref is set and are only intended for testing. There's also a new method resetStoragesForPrincipal() which is used as a callback for close() since datastores don't release directory locks immediately. resetStoragesForPrincipal() requests an exclusive lock for given origin, so it must wait for any exising shared locks to be released.
This should make BrowsingContext more usable by making it much easier to obtain
for a given frame or browser. BrowsingContext and nsFrameLoader should have
the same lifetime.
Differential Revision: https://phabricator.services.mozilla.com/D9395
1. Add a new method nsIPaymentRequestService::ChangePaymentMethod for UI to
inform merchant the payment method is changed by user.
2. Add a new method in PPaymentRequest.ipdl to passing the changing method
information from chrome process to content process.
3. Add BasicCardChangeDetails dictionary in BasicCardPayment.webidl
4. Create ChangeDetails, GeneralDetails and BasicCardDetails for saving the
the method information in content process.
--HG--
extra : histedit_source : 8426da9c1d070daa35623b3431341c13cb361aed
This should make BrowsingContext more usable by making it much easier to obtain
for a given frame or browser. BrowsingContext and nsFrameLoader should have
the same lifetime.
Differential Revision: https://phabricator.services.mozilla.com/D9395
1. Add a new method nsIPaymentRequestService::ChangePaymentMethod for UI to
inform merchant the payment method is changed by user.
2. Add a new method in PPaymentRequest.ipdl to passing the changing method
information from chrome process to content process.
3. Add BasicCardChangeDetails dictionary in BasicCardPayment.webidl
4. Create ChangeDetails, GeneralDetails and BasicCardDetails for saving the
the method information in content process.
Bug 1489040 - P1 - Update WebRTC ICE candidate stats field ipAddress to new name, address
Bug 1489040 - P2 - adjust WebRTC stats mochitest for new stat name 'address'
Bug 1489040 - P3 - add test for legacy WebRTC stat names
Differential Revision: https://phabricator.services.mozilla.com/D5560
--HG--
extra : moz-landing-system : lando