- Adds CONFIRM_TRYING_FAILED confirmation state. We use this state when we retry confirmation after confirmation fails.
- Rename CONFIRM_TRYING to CONFIRM_TRYING_OK. We use this state when we try confirmation but no confirmation failure has happened.
- Rename CONFIRM_INIT to CONFIRM_OFF. We use this state whenever there is an event that would disable TRR - such as a TRR mode change.
- Add CONFIRM_DISABLED confirmation state. We use this state in mode3 or when confirmationNS=="skip"
- To potentially allow us to have the same behaviour as after Bug 1689113, specifically the we might be able to report TRRService::Enabled = true when retrying and the state is CONFIRM_TRYING_FAILED we added `network.trr.attempt-when-retrying-confirmation`
- After a large number of TRR failures occurs, we immediately trigger another confirmation and go into CONFIRM_TRYING_OK. This allows us to cope with a temporary increase in network latency that is smaller than 6s.
- We no longer trigger confirmation for nsIRequest::TRR_FIRST_MODE when the resolver mode is not TRR_FIRST. This allows us to simplify the code.
- test_trr_proxy.js now calls trr_test_setup() after it sets up the pac script to avoid confirmation causing non-local connections in tests.
- Moves all the confirmation state handing into HandleConfirmationEvent
Differential Revision: https://phabricator.services.mozilla.com/D107666
For that, we make accessibility.mouse_focuses_formcontrol a static pref,
and make it work in all platforms because it's simpler and allows to
test mac-specific things on other platforms more easily.
Differential Revision: https://phabricator.services.mozilla.com/D109006
This parsing is hidden behind the pref layout.css.page-size.enabled.
It isn't ideal that we parse this as a property, but we can't treat it as a
descriptor because of compatibility issues with other browsers. There are also
outstanding spec issues related to how descriptors like page-size are cascaded,
and whether the !important specifier is valid or not.
Differential Revision: https://phabricator.services.mozilla.com/D103958
This aligns Mac's focus model with other platforms. Matches Chromium, but not
Safari.
Reasons why I think it's worth making this change:
* Consistency with all other platforms.
* Makes the :focus-visible implementation more useful.
* Fixes focus navigation after e.g. clicking a button.
* Shouldn't cause a lot more outlines to show up (at least not by default).
An example of the second point:
data:text/html,<button onclick="this.nextElementSibling.focus()">Click</button><button>Imagine I'm a dialog close button or something</button>
In non-macOS platforms, we won't show an outline for the button in that case,
which matches the developer expectations (links below). We don't show the
outline because the focus comes from an element that has been focused by mouse
(and thus didn't show an outline). But on macOS that doesn't work, because the
button is not focused.
For completeness, the actual heuristics for :focus-visible may change a bit as
a result of the discussions in:
* https://github.com/w3c/csswg-drafts/issues/5885
* https://github.com/web-platform-tests/wpt/pull/27806
But it's not clear to me how to best define this so it works on the macOS focus
model.
An example of the third point:
data:text/html,<input type=text><input type=submit><input type=text>
On Safari and Chrome (and Firefox on non-macOS platforms), clicking the button,
then pressing tab, goes to the input on the right. In Firefox on macOS it
doesn't because the button doesn't gain focus nor is selectable.
Differential Revision: https://phabricator.services.mozilla.com/D108808
This parsing is hidden behind the pref layout.css.page-size.enabled.
It isn't ideal that we parse this as a property, but we can't treat it as a
descriptor because of compatibility issues with other browsers. There are also
outstanding spec issues related to how descriptors like page-size are cascaded,
and whether the !important specifier is valid or not.
Differential Revision: https://phabricator.services.mozilla.com/D103958
This pref is used for testing purposes and forces all widgets to use the
same compositor. If the user is configured for WebRender, all will use
WebRender. If the user is configured for Software WebRender, all will
use Software WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D108663
In Phase 1, both Ion and Cranelift are available, and the default is switched
to Cranelift. Use --wasm-force-ion or --wasm-compiler=ion at the shell to
select Ion, or make sure javascript.options.wasm_force_ion is true in
about:config. Phase 1 is appropriate for fuzzing, after the patch set lands
in mozilla-central but before Ion is enabled by default. The patch for Phase
1 will appear on bug 1678097 and will be very small, and MUST land with the
patch for Phase 0.
Differential Revision: https://phabricator.services.mozilla.com/D101867
In Phase 0, both Cranelift and Ion are available on arm64, and Ion is the
default. Use --wasm-force-cranelift or --wasm-compiler=cranelift at the shell
to select Cranelift, or set javascript.options.wasm_force_ion to false in
about:config. Phase 0 is appropriate for developers, before the patch set
lands in mozilla-central and before SIMD is present.
In Phase 1, both compilers are still available, but the default is switched to
Cranelift. Use --wasm-force-ion or --wasm-compiler=ion at the shell to select
Ion, or make sure javascript.options.wasm_force_ion is true in about:config.
Phase 1 is appropriate for fuzzing, after the patch set lands in
mozilla-central but before Ion is enabled by default. The patch for Phase 1
will appear on bug 1678097 and will be very small, and MUST land with the
patch for Phase 0.
In Phase 0 and Phase 1, --wasm-compiler=cranelift and --wasm-compiler=ion are
both accepted, and do the expected thing.
In Phase 2, Cranelift becomes disabled in moz.configure and all the changes in
the present patch are removed again. The patch for Phase 2 will appear on bug
1686626 and will revert Phase 0 and Phase 1, and additionally update
moz.configure.
Differential Revision: https://phabricator.services.mozilla.com/D102420
We seem to have cargo-culted this in from nearby gfx code, but since we read
prefs only during the spidermonkey prefs callback this is a bit silly. Note
that the Streams cases *do* make use of off-thread uses of the mirror
variable from within Gecko.
Differential Revision: https://phabricator.services.mozilla.com/D108127
To simplify this code, turns these prefs into unlisted prefs on MIPS
platforms since the JIT support is missing there. The JitOptions will
continue to default them to false on MIPS.
Differential Revision: https://phabricator.services.mozilla.com/D108107
Mark these prefs as 'do_not_use_directly` to avoid confusion since they
should only be snapshotted once in `LoadStartupJSPrefs`. We cannot use the
`once` mirrors here since they are not available until after the
EnterprisePolicies code has ran and that itself uses javascript.
Differential Revision: https://phabricator.services.mozilla.com/D108104
This dates back to a time before the browser console where the normal content
console could optionally show chrome code messages. Today it serves no use.
Differential Revision: https://phabricator.services.mozilla.com/D108130
Win32k Lockdown is getting to the point where we *could* have people in the
community start testing. Let's make it easy for them!
Differential Revision: https://phabricator.services.mozilla.com/D108255
In Phase 1, both Ion and Cranelift are available, and the default is switched
to Cranelift. Use --wasm-force-ion or --wasm-compiler=ion at the shell to
select Ion, or make sure javascript.options.wasm_force_ion is true in
about:config. Phase 1 is appropriate for fuzzing, after the patch set lands
in mozilla-central but before Ion is enabled by default. The patch for Phase
1 will appear on bug 1678097 and will be very small, and MUST land with the
patch for Phase 0.
Differential Revision: https://phabricator.services.mozilla.com/D101867
In Phase 0, both Cranelift and Ion are available on arm64, and Ion is the
default. Use --wasm-force-cranelift or --wasm-compiler=cranelift at the shell
to select Cranelift, or set javascript.options.wasm_force_ion to false in
about:config. Phase 0 is appropriate for developers, before the patch set
lands in mozilla-central and before SIMD is present.
In Phase 1, both compilers are still available, but the default is switched to
Cranelift. Use --wasm-force-ion or --wasm-compiler=ion at the shell to select
Ion, or make sure javascript.options.wasm_force_ion is true in about:config.
Phase 1 is appropriate for fuzzing, after the patch set lands in
mozilla-central but before Ion is enabled by default. The patch for Phase 1
will appear on bug 1678097 and will be very small, and MUST land with the
patch for Phase 0.
In Phase 0 and Phase 1, --wasm-compiler=cranelift and --wasm-compiler=ion are
both accepted, and do the expected thing.
In Phase 2, Cranelift becomes disabled in moz.configure and all the changes in
the present patch are removed again. The patch for Phase 2 will appear on bug
1686626 and will revert Phase 0 and Phase 1, and additionally update
moz.configure.
Differential Revision: https://phabricator.services.mozilla.com/D102420
Should be much simpler and doesn't need to deal with the different
stuff. We already have pseudo-classes for this, :autofill and
:placeholder-shown.
I initially wrote this because this is the only limitation that forces
us to have the placeholder text as a direct child of the text control
frame. In the end I kept that as-is, but this simplification is still
worth it.
We remove dom.placeholder.show_on_focus because it doesn't behave
correctly (it doesn't match the :placeholder-shown pseudo-class and it
should). It was introduced in bug 807613 and never turned to false by
default. I suspect nobody will miss this, but if somebody complains
about it we can reintroduce it properly (handling the pref in DOM
instead, changing the right state bits).
Differential Revision: https://phabricator.services.mozilla.com/D108304
The "barriers" here refered to type-barriers which no longer exist after
IonBuilder was removed so this pref is now dead. Also remove the .misc suffix
of the sibling pref.
Differential Revision: https://phabricator.services.mozilla.com/D108123
We seem to have cargo-culted this in from nearby gfx code, but since we read
prefs only during the spidermonkey prefs callback this is a bit silly. Note
that the Streams cases *do* make use of off-thread uses of the mirror
variable from within Gecko.
Differential Revision: https://phabricator.services.mozilla.com/D108127
To simplify this code, turns these prefs into unlisted prefs on MIPS
platforms since the JIT support is missing there. The JitOptions will
continue to default them to false on MIPS.
Differential Revision: https://phabricator.services.mozilla.com/D108107
