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
Currently, some "input" event dispatchers in our script dispatch "input" event
with UIEvent. This is completely wrong. For conforming to HTML spec, Event
is proper event. Additionally, for conforming to Input Events, InputEvent
is proper event only on <textarea> or <input> element which has a single line
editor.
For making us to maintain easier, this patch adds new API, "isInputEventTarget"
to MozEditableElement which returns true when "input" event dispatcher should
use InputEvent for the input element.
Finally, this makes some dispatchers use setUserInput() instead of
setting value and dispatching event by themselves. This also makes
us to maintain them easier.
Note that this does not touch "input" event dispatchers which dispatch events
only for chrome (such as URL bar, some pages in about: scheme) for making
this change safer as far as possible.
Differential Revision: https://phabricator.services.mozilla.com/D12247
--HG--
extra : moz-landing-system : lando
This patch makes it to spoof the pointer id into mouse pointer id
when resistfingerprinting is enabled. And we will only spoof for
content but not for chrome. Since we don't know the pointer id
beforehand, we have to cache the pointer id of the mouse interface when
it is activated. And use that pointer for the purpose of fingerprinting
resistance.
Differential Revision: https://phabricator.services.mozilla.com/D9531
--HG--
extra : moz-landing-system : lando
The patch adds the support of referrerpolicy attribute in script element
and take the attribute into account when loading script.
Differential Revision: https://phabricator.services.mozilla.com/D11637
--HG--
extra : moz-landing-system : lando
Previously, the tabindex attribute wasn't supported on non-control XUL elements at all.
The only way to make those focusable was to use -moz-user-focus: normal.
However, that caused the element to be included in the tab order; there was no way to make it focusable but not tabbable.
This can now be achieved using tabindex="-1".
This will primarily be useful for buttons on toolbars, which will be grouped under a single tab stop for efficiency.
For consistency, this also changes the behaviour of tabindex="-1" with -moz-user-focus: ignore on XUL controls.
Previously, -moz-user-focus: ignore would override tabindex="-1", making the element unfocusable.
Now, the tabindex attribute always overrides if explicitly specified.
Differential Revision: https://phabricator.services.mozilla.com/D12000
--HG--
extra : moz-landing-system : lando
Rather than adding a native type for nsID objects in WebIDL, this patch just
takes the approach of switching consumers over to using 'any' and calling the
APIs defined in Part 1.
Differential Revision: https://phabricator.services.mozilla.com/D2283
- Expose FetchEvent.resultingClientId on non-subresource, non-"report"-destination requests.
- Delay Clients.get(FetchEvent.resultingClientId) resolution until the resulting client is execution ready.
- Add WPTs to test for existence of resultingClientId and Clients.get promise resolution values.
Differential Revision: https://phabricator.services.mozilla.com/D5333
--HG--
extra : moz-landing-system : lando
This patch removes the following functions:
* nsContentUtils::IsCustomElementsEnabled()
* CustomElementRegistry::IsCustomElementEnabled(JSContext* aCx, JSObject* aObject)
* CustomElementRegistry::IsCustomElementEnabled(nsIDocument* aDoc)
and all references of the pref.
Depends on D11183
Differential Revision: https://phabricator.services.mozilla.com/D11249
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
This patch removes the following functions:
* nsContentUtils::IsCustomElementsEnabled()
* CustomElementRegistry::IsCustomElementEnabled(JSContext* aCx, JSObject* aObject)
* CustomElementRegistry::IsCustomElementEnabled(nsIDocument* aDoc)
and all references of the pref.
Depends on D11183
Differential Revision: https://phabricator.services.mozilla.com/D11249
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
This adds a new class for the marquee tag, instead of overloading HTMLDivElement.
It removes some of the XBL that was used to expose properties to web content.
Differential Revision: https://phabricator.services.mozilla.com/D3824
--HG--
extra : moz-landing-system : lando
This resolves the two problems of MediaRecorder:
1. MediaRecorder does not fire pause/resume events when the corresponding methods are called, as mentioned in D7910.
2. The WebIDL for MediaRecorder does not specify onpause/onresume event handler attributes neither.
DispatchSimpleEvent() is used because there are no event attributes needed.
Differential Revision: https://phabricator.services.mozilla.com/D7971
--HG--
extra : moz-landing-system : lando
- Expose FetchEvent.resultingClientId on non-subresource, non-"report"-destination requests.
- Delay Clients.get(FetchEvent.resultingClientId) resolution until the resulting client is execution ready.
- Add WPTs to test for existence of resultingClientId and Clients.get promise resolution values.
Differential Revision: https://phabricator.services.mozilla.com/D5333
--HG--
extra : moz-landing-system : lando
The concept of card types, supportedTypes, BasicCardType enum, were removed from the Basic Card spec.
Differential Revision: https://phabricator.services.mozilla.com/D10646
--HG--
extra : moz-landing-system : lando
This has never been specced and is unused appart from our tests.
Differential Revision: https://phabricator.services.mozilla.com/D10082
--HG--
extra : rebase_source : c044f11325ec630dcabb673c85531a2283ff6ad4
extra : source : db3c2a88f79cb28440f4e13bcf27c5165c6ee060
This has never been specced and is unused appart from our tests.
Differential Revision: https://phabricator.services.mozilla.com/D10082
--HG--
extra : rebase_source : 4c54d808fb69c0e403ff2e1775b97571889efca4
extra : histedit_source : bc568066b0684bb82b4f553b99f0dd48212aa633
This patch converts datetimebox.xml to datetimebox.js and loads it as a UA Widget,
while touches things here and there to make it work.
In HTMLInputElement manages the lifecycle of the datetimebox UA Widget.
It is loaded when in <input> has type date or time, or have its type switch to date or time.
nsDateTimeControlFrame is changed so that when UA Widget is enabled,
it would not generate <xul:datetimebox>.
Like bug 1483972, a check is added in nsCSSFrameConstructor::CreateGeneratedContentItem()
to make sure we don't generate pseudo content inside <input>.
Assertions in IntlUtils is changed to allow UAWidget to call the methods.
Depends on D9056
Differential Revision: https://phabricator.services.mozilla.com/D9057
--HG--
rename : toolkit/content/widgets/datetimebox.xml => toolkit/content/widgets/datetimebox.js
extra : moz-landing-system : lando
This patch simplifies the nsIDateTimeInputArea interface, implemented by the
datetimebox bindings, to a point that is easier to convert it to dispatch events,
by doing the following:
- hasBadInput() is re-implemented in C++ in nsIDateTimeControlFrame since
C++ needs the return value synchronously.
- SetValueFromPicker() and SetPickerState() are avoided completed since they
are simply called by HTMLInputElement methods exposed to the frame
script. They are avoided by having the frame script access the NAC and call
the nsIDateTimeInputArea methods directly.
- Merge setEditAttribute() and removeEditAttribute() to updateEditAttributes()
which takes no arguments, and have the method access the attribute values by
reading the values from <input>.
This patch is a scaled-down version of the patch proposed in bug 1456833.
The event approach is only usable in UA Widget version of datetimebox because
there is no way to avoid leaking events to the document without Shadow DOM.
Differential Revision: https://phabricator.services.mozilla.com/D9056
--HG--
extra : moz-landing-system : lando
There is a limited number of these, and this allows me to completely remove
mention of the 'System' global.
In the future System-only exposure could be achieved using a [Func] enabler.
Differential Revision: https://phabricator.services.mozilla.com/D9400
We don't need to expose on both Window and System anymore, as Window now
implies System. I don't remove unnecessary [Exposed=Window] annotations, as
WebIDL upstream has removed PrimaryGlobal.
Differential Revision: https://phabricator.services.mozilla.com/D9399
The main change is to just use the principal bindings pass us to do our
CheckLoadURI check. If we do that, we don't have to care about the current
JSContext.
The WG rejected this extension.
--HG--
rename : dom/canvas/test/webgl-mochitest/ensure-exts/test_WEBGL_compressed_texture_es3.html => dom/canvas/test/webgl-mochitest/ensure-exts/test_WEBGL_compressed_texture_etc.html
The maxTouchPoints is going to review the detail of users' hardware. So,
we will spoof it into 0 if fingerprinting resistance is on.
Depends on D6004
Differential Revision: https://phabricator.services.mozilla.com/D6005
--HG--
extra : moz-landing-system : lando
The pointerType field in the pointer event will reveal the details of
users' hardware; this is a fingerprinting vector. So, we would spoof all
types of pointer events into mouse type pointer events for protecting
users from browser fingerprinting when fingerprinting resistance is on.
In this patch, we would spoof the pointerType as well as other fields
that mouse pointer events don't support, like pressure, tiltX/Y and so
on when fingerprinting resistance is on.
Differential Revision: https://phabricator.services.mozilla.com/D6003
--HG--
extra : moz-landing-system : lando
Chrome sets both KeyboardEvent.keyCode and KeyboardEvent.charCode of "keypress"
event to same value. On the other hand, our traditional behavior is, sets
one of them to 0.
Therefore, we need to set keyCode value to charCode value if the keypress
event is caused by a non-function key, i.e., it may be a printable key with
specific modifier state and/or different keyboard layout for compatibility
with Chrome. Similarly, we need to set charCode value to keyCode value if
the keypress event is caused by a function key which is not mapped to producing
a character.
Note that this hack is for compatibility with Chrome. So, for now, it's enough
to change the behavior only for "keypress" event handlers in web content. If
we completely change the behavior, we need to fix a lot of default handlers
and mochitests too. However, it's really difficult because default handlers
check whether keypress events are printable or not with following code:
> if (event.charCode &&
> !event.altKey && !event.ctrlKey && !event.metaKey) {
or
> if (!event.keyCode &&
> !event.altKey && !event.ctrlKey && !event.metaKey) {
So, until we stop dispatching "keypress" events for non-printable keys,
we need complicated check in each of them.
And also note that this patch changes the behavior of KeyboardEvent::KeyCode()
when spoofing is enabled and the instance is initialized by initKeyEvent() or
initKeyboardEvent(). That was changed by bug 1222285 unexpectedly and keeping
the behavior makes patched code really ugly. Therefore, this takes back the
old behavior even if spoofing is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D7974
--HG--
extra : moz-landing-system : lando
Synthesizing keyboard events is dangerous and such API is requested only by
fuzzing test. So, we should add it into FuzzingFunctions which is built
only when |ac_add_options --enable-fuzzing| is specified and enabled by
the pref.
This patch implements the API as synthesizing keyboard events in the focused
widget and the synthesized events are propagated as native key events except
APZ (because keyboard events are synthesized only in the process). This
behavior allows to test including any default action handlers such as
EventStateManager and setting WidgetGUIEvent::mWidget since some C++ handler
checks if it's nullptr.
Differential Revision: https://phabricator.services.mozilla.com/D5516
--HG--
extra : moz-landing-system : lando
This commit initially exposes the drawSnapshot API off of <browser>. This
is done by adding a WebIDL binding to FrameLoader and wrapping it in
browser.xml.
Differential Revision: https://phabricator.services.mozilla.com/D6791
--HG--
extra : rebase_source : 9f819b13c102edf42ab2bb2466578751a7a2f647
StructuredCloneTester objects can configured to be serializable (or not) and
deserializable (or not) by the structured clone algorithm. They can be used to
test, for example, onmessageerror event handlers, where the messageerror event
is fired when a message fails to be deserialized (but was successfully serialized).
The class is pref'ed with "dom.testing.structuredclonetester.enabled".
Differential Revision: https://phabricator.services.mozilla.com/D5207
--HG--
extra : moz-landing-system : lando
StructuredCloneTester objects can configured to be serializable (or not) and
deserializable (or not) by the structured clone algorithm. They can be used to
test, for example, onmessageerror event handlers, where the messageerror event
is fired when a message fails to be deserialized (but was successfully serialized).
The class is pref'ed with "dom.testing.structuredclonetester.enabled".
Differential Revision: https://phabricator.services.mozilla.com/D5207
--HG--
extra : moz-landing-system : lando
This partially backs out bug 1471165 now that we don't enforce a default value
for dictionary-typed members of dictionaries.
Differential Revision: https://phabricator.services.mozilla.com/D6876
--HG--
rename : testing/web-platform/meta/media-capabilities/decodingInfo.html.ini => testing/web-platform/meta/media-capabilities/encodingInfo.html.ini
rename : testing/web-platform/tests/media-capabilities/decodingInfo.html => testing/web-platform/tests/media-capabilities/encodingInfo.html
extra : moz-landing-system : lando
Add the first version of the IPDL-JS API, which allow chrome JS to load IPDL files and use them to communicate accross Content processes.
See IPDLProtocol.h for more information regarding how to use the API.
Differential Revision: https://phabricator.services.mozilla.com/D2116
--HG--
rename : ipc/moz.build => ipc/ipdl_new/moz.build
extra : moz-landing-system : lando
Some steps in file_fullscreen-api.html are adjusted in order to test
the behavior that the event is correctly dispatched to the document
when element is disconnected.
Depends on D5415
Differential Revision: https://phabricator.services.mozilla.com/D5416
--HG--
extra : moz-landing-system : lando
To support merchants providing the payment details with errors by
PaymentRequestUpdateEvent.updateWith() during PaymentResponse.retry(),
PaymentDetailsUpdate needs to add more two attributes in webidl.
dictionary PaymentDetailsUpdate {
...
PayerErrorFields payerErrors;
object paymentMethodErrors;
};
And transfer these error field to UI component
1. Add PaymentValidationErrors and PayerErrorFields in PaymentRequest.webidl
and PaymentResponse.retry() in PaymentResponse.webidl
2. Implement PaymentRequest.retryPayment() and
PaymentRequestManager.retryPayment() in content process.
3. Add IPCPaymentRetryActionRequest in PPaymentRequest.ipdl to transfer the
error fields to chrome process.
4. Implement PaymentResponse.retry() by reusing the code of show() and
updateWith() of PaymentRequestService in chrome process.
Streams have multiple parts that can be JS objects from different compartments.
For example, the [[reader]] internal slot of a stream can point to a reader
object in another compartment.
This patch makes the ReadableStream implementation robust against mixing and
matching stream-related objects and methods from different globals.
This also removes ReadableStreamBYOBReader and ReadableStreamBYOBRequest for
now, with a view toward enabling basic ReadableStream features by default in
bug 1389628.
Differential Revision: https://phabricator.services.mozilla.com/D8450
--HG--
extra : rebase_source : 71d73bed5bc82557efcb6b1ecb231275fd3e1189
extra : amend_source : de29f663b9929eb2858b23cc6f4e7ba97b23a28c
extra : source : f91eb962df6a06d5f51ad13caa2a4a9c2947f293
Summary:
DocumentL10n is a DOM C++ API which serves as a bridge between
nsIDocument and mozDOMLocalization APIs.
MozReview-Commit-ID: 8LfOR4Haqlu
Reviewers: smaug
Reviewed By: smaug
Subscribers: mossop, smaug
Bug #: 1455649
Differential Revision: https://phabricator.services.mozilla.com/D2904
--HG--
extra : rebase_source : f57f363532ecc3456fb9ada734bda5b63b5ba511
While trying to repro bug 1484293 I noticed that this assertion failed:
https://searchfox.org/mozilla-central/rev/ef8b3886cb173d5534b954b6fb7eb2d94a9473d0/dom/base/ShadowRoot.cpp#160
(during unlink, while unbinding the kids)
We rely on GetComposedDoc returning the right thing during unbind to cleanup
some stuff (see bug 1473637 for example), so it should probably be correct all
the time, regardless of whether something is unlinked or not.
Also this makes GetComposedDoc() much faster, which is nice too, since we call
it somewhat often.
I removed NodeHasRelevantHoverRules, since it's unused (was used by the old
style system).
I moved the SetIsConnected(false) call for the shadow root to before unbinding
the kids for consistency with what Element does with the uncomposed doc flag,
now that the children's connectedness doesn't depend on the shadow root's.
Differential Revision: https://phabricator.services.mozilla.com/D3715
--HG--
extra : moz-landing-system : lando
While trying to repro bug 1484293 I noticed that this assertion failed:
https://searchfox.org/mozilla-central/rev/ef8b3886cb173d5534b954b6fb7eb2d94a9473d0/dom/base/ShadowRoot.cpp#160
(during unlink, while unbinding the kids)
We rely on GetComposedDoc returning the right thing during unbind to cleanup
some stuff (see bug 1473637 for example), so it should probably be correct all
the time, regardless of whether something is unlinked or not.
Also this makes GetComposedDoc() much faster, which is nice too, since we call
it somewhat often.
I removed NodeHasRelevantHoverRules, since it's unused (was used by the old
style system).
I moved the SetIsConnected(false) call for the shadow root to before unbinding
the kids for consistency with what Element does with the uncomposed doc flag,
now that the children's connectedness doesn't depend on the shadow root's.
Differential Revision: https://phabricator.services.mozilla.com/D3715
--HG--
extra : moz-landing-system : lando