We always use PreventDefault for <select> element, which is
problematic if modal dialog is on as it prevents cancelling
the dialog.
We fix it by not blocking the default action if <select> is
not shown.
Differential Revision: https://phabricator.services.mozilla.com/D82590
See bug 1606660 comment 8 as to why checking it only in
Element.requestFullscreen is wrong.
Do you know how to test this? I'm not very familiar with feature-policy.
Differential Revision: https://phabricator.services.mozilla.com/D78567
Mozilla consider that we should protect even Nightly testers from the behavior
change of bug 1320229.
And I forgot to modify the new mochitest for bug 1635224 which is a regression
of bug1320229.
Differential Revision: https://phabricator.services.mozilla.com/D78841
Per https://html.spec.whatwg.org/#selector-read-write:
> The :read-write pseudo-class must match any element falling into one
> of the following categories [...]:
>
> * input elements to which the readonly attribute applies, and that
> are mutable (i.e. that do not have the readonly attribute
> specified and that are not disabled)
>
> * textarea elements that do not have a readonly attribute, and
> that are not disabled.
>
> * elements that are editing hosts or editable and are neither
> input elements nor textarea elements.
This fixes the `:disabled` bits.
This matches Safari behavior and the spec, but not Chrome, which has our
behavior.
Fix the WPT, which had multiple issues, as :read-only is defined to be
just the opposite of :read-write. This will pass as soon as I unprefix
the pseudo-class.
Differential Revision: https://phabricator.services.mozilla.com/D75230
This should make it easier to write tests for race-conditions, as
the resolving value now indicates which event was received.
This required updating a test which for some reason asserted
undefined being the resolving value, as a way of "testing" if the
Promise resolved at all. Since await already throws Errors when it
is rejected, and the test throws a timeout if it doesn't resolve in
time, this assertion was removed. It did not add any value.
Differential Revision: https://phabricator.services.mozilla.com/D74124
Modify PresState's string variant to also store whether the last change was
interactive, and preserve that property when saving and restoring state.
Differential Revision: https://phabricator.services.mozilla.com/D73920
This patch removes the allowLinkedWebInFileUriProcess pref, but one
code-path is kept because when DocumentChannel is disabled a HTTP POST load
from a file:// page would loose the postData, so that case keeps the FILE
remote type.
Differential Revision: https://phabricator.services.mozilla.com/D69923
We need it to live in BrowsingContext instead of WindowContext, because
we need to preserve the zoom level across same-origin navigation.
It'd be nice if it only lived in the top BC, but that's not possible at
the moment because a lot of tests rely on zooming only iframes. Some of
them can be adjusted for scaling the top instead, but not sure it's
worth it's worth fixing them and moving the zoom to be top-only, as it'd
be a bunch of effort, and the complexity and overhead of propagating the
zoom is not so big.
The print-preview-specific code in nsContentViewer is from before we did
the document cloning setup, and it seems useless. I've tested print
preview scaling before and after my patch and both behave the same.
The rest is just various test changes to use the SpecialPowers APIs or
BrowsingContext as needed instead of directly poking at the content
viewer.
I named the pres context hook RecomputeBrowsingContextDependentData, as
more stuff should move there like overrideDPPX and other media emulation
shenanigans.
I also have some ideas to simplify or even remove ZoomChild and such,
but that's followup work.
Differential Revision: https://phabricator.services.mozilla.com/D71969
`inputmode` attribute controls software keyboard layout like `<input type>`.
Originally this was by B2G (bug 746142) and for `<input>` element only.
WHATWG spec allows this attribute for HTML element and WebKit and Blink have
already implemented this.
Differential Revision: https://phabricator.services.mozilla.com/D69348
--HG--
extra : moz-landing-system : lando
The top-level document containing the iframe in which the test runs can be
scrolled by things that happen in previous tests (e.g. a zoomToFocusedInput
in a previous test), causing the target element to be outside of the visual
viewport.
After bug 1556556, event synthesization functions will no longer support
targeting elements outside the visual viewport.
Differential Revision: https://phabricator.services.mozilla.com/D67523
--HG--
extra : moz-landing-system : lando
This restores our previous behavior with the new <input type=number>
implementation (see the changes in test_input_number_l10n.html, which undoes the
changes of the regressing bug), and adds a test that shows that we display the
localized value properly.
Differential Revision: https://phabricator.services.mozilla.com/D66822
--HG--
extra : moz-landing-system : lando
Make the features parameter of window.open just a condition for whether to open
a popup or a new tab.
Also remove dom.disable_window_open_feature.* prefs.
Differential Revision: https://phabricator.services.mozilla.com/D65926
--HG--
extra : moz-landing-system : lando
Make the features parameter of window.open just a condition for whether to open
a popup or a new tab.
Also remove dom.disable_window_open_feature.* prefs.
Differential Revision: https://phabricator.services.mozilla.com/D65926
--HG--
extra : moz-landing-system : lando
