And add code to use the appropriate variant like we do in macOS with
respect-system-appearance (but this still needs more work as noted in
StaticPrefList.yaml).
Still, it cleans up a bunch, and allows to not depend on the content
process boundary to provide light system colors.
Depends on D113542
Differential Revision: https://phabricator.services.mozilla.com/D113543
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
And add code to use the appropriate variant like we do in macOS with
respect-system-appearance (but this still needs more work as noted in
StaticPrefList.yaml).
Still, it cleans up a bunch, and allows to not depend on the content
process boundary to provide light system colors.
Depends on D113542
Differential Revision: https://phabricator.services.mozilla.com/D113543
This will allow detecting the system theme, which allows fixing some of
the blocked bugs.
Note that when using the system theme we will still match light or dark
appropriately, so this shouldn't change behavior just yet.
Differential Revision: https://phabricator.services.mozilla.com/D113516
This test is for documentation purposes. You may run it locally on Windows by removing the skip-if = true from xpcshell.ini
As sharing folders on windows requires elevated priviledges, you will need to execute some commands in a separate cmd.exe instance with Admin priviledges.
Differential Revision: https://phabricator.services.mozilla.com/D113498
We've been using 3 on Nightly for a long time without
any problems and it's generally much better to keep the GPU
process around than give up on it.
We also bump the Nightly value to increase the chances of us
finding any problems where we should give up on using the GPU process.
Differential Revision: https://phabricator.services.mozilla.com/D113393
CLOSED TREE
Backed out changeset 9dea771db2ce (bug 1703934)
Backed out changeset 2a51d2530939 (bug 1703934)
Backed out changeset 6af76624ce86 (bug 1703934)
Fractional scaling currently comes at a high performance cost as we
only support integer scaling for rendering. The overdraw ratio is
something like (ceil(scale) / scale)^2, which for 125% scaling means
we're drawing 2.56 times as much as we should.
In theory we already support everything needed to have proper fractional
scaling: Webrender support appears to be in great shape and on the Wayland
side we can use the wp_viewporter protocol to have arbitrary
buffer size <-> surface size relationships. The main blocker remains the
lack of proper negotiation between client and compositor about the
optimal buffer size.
In order to speed up the upstream discussion, lets implement it via a
fixed value that can be set in `about:config` for testing purposes
(`widget.wayland.fractional_buffer_scale`).
It will, of course, require wp_viewporter support from the compositor.
Differential Revision: https://phabricator.services.mozilla.com/D113321
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486
This is a bit subtler than needed (ideally we'd just need one pref)
because android enables the support for the type even if it only creates
a textbox.
Co-Authored-By: Fernando García <fernando.garciagomez.01@telefonica.com>
Differential Revision: https://phabricator.services.mozilla.com/D112488
This property does nothing since bug 315209 got implemented.
Every single user that I checked was doing the same math by hand, so
hooray for good defaults :-)
Differential Revision: https://phabricator.services.mozilla.com/D112253
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486
This patch introduces a new way to way to schedule input tasks, such
that input tasks remain at `InputHigh` priority normally, however, when
there's a pending `Vsync` priority task in the task queue, we
increase the priority of input tasks from `InputHigh` to `InputHighest` to
rush processing the pending input tasks.
There are two restrictions to ensure we don't delay vsync too much:
- There's a hard limit duration
- We won't process the input tasks that are newly added after we've
started to process the current number of input tasks
Differential Revision: https://phabricator.services.mozilla.com/D109499
This patch enables Ion by default as the optimising compiler for wasm on
AArch64, and disables Cranelift. Cranelift is still available if the build is
configured with --enable-cranelift. In that case, *only* Cranelift is
available. There are no configuration flags to enable both Ion and Cranelift
simultaneously.
This mostly reverts the Phase 0 and Phase 1 patches that are bug 1678097
D102420 and D101867 respectively.
The command line option --wasm-force-ion has been removed.
With this patch in place, users of the shell should specify
`--wasm-compiler=optimizing` to get an optimising wasm compiler. Which one is
provided depends on the configuration options as described above.
`--wasm-compiler=cranelift` and `--wasm-compiler=ion` are now only accepted
when the relevant compiler has been enabled, and so neither is a "safe" way to
request an optimising tier.
For that reason, test directories that previously requested
also-with-Ion-please by stating `test-also=--wasm-compiler=ion;` in their
`directives.txt` file, have been changed to use
`test-also=--wasm-compiler=optimizing;`.
In places where the JSContextOptions are set, the non-selected compiler (Ion
or CL) is explicitly set to `false` (eg, `.setWasmIon(false)`). This may be
overly conservative, but seems wise given that it's not immediately obvious
what the previous value of that flag is, and given the recent difficulties
with incorrect option propagation/handling (eg, bug 1697560).
Differential Revision: https://phabricator.services.mozilla.com/D101695
This patch turns on Software WebRender for all widgets that don't get
acceleration by default on nightly and early beta, as well as for users
who are put into the Fission experiment. It also cleans up our prefs to
simply enable it for all popups, and not just those affected by Fission.
Differential Revision: https://phabricator.services.mozilla.com/D111958
Safari does this. This reduces the runtime in the example linked from
comment 0 quite a lot (40ms on a local opt build, from ~130ms on a
release nightly build).
I added a pref because there's a slight chance of performance
regressions on pages that do not use attribute selectors, as we're now
doing more unconditional work per element (adding the attributes to the
bloom filter). But the trade-off should be worth it, I think.
Differential Revision: https://phabricator.services.mozilla.com/D111689
Do the minimal amount of work to flip the default sense of the pref from false
to true.
One test case had to be tweaked because it assumed a 2GB max and we had not
stressed this with the --large-arraybuffer switch.
Added a test for the --no-large-arraybuffer switch.
Various test cases had to be tweaked to use the largeArrayBufferEnabled
predicate to guard tests that assumed specific buffer sizes, when those tests
could not easily be updated.
Differential Revision: https://phabricator.services.mozilla.com/D111100
This patch enables Ion by default as the optimising compiler for wasm on
AArch64, and disables Cranelift. Cranelift is still available if the build is
configured with --enable-cranelift. In that case, *only* Cranelift is
available. There are no configuration flags to enable both Ion and Cranelift
simultaneously.
This mostly reverts the Phase 0 and Phase 1 patches that are bug 1678097
D102420 and D101867 respectively.
The command line option --wasm-force-ion has been removed.
With this patch in place, users of the shell should specify
`--wasm-compiler=optimizing` to get an optimising wasm compiler. Which one is
provided depends on the configuration options as described above.
`--wasm-compiler=cranelift` and `--wasm-compiler=ion` are now only accepted
when the relevant compiler has been enabled, and so neither is a "safe" way to
request an optimising tier.
For that reason, test directories that previously requested
also-with-Ion-please by stating `test-also=--wasm-compiler=ion;` in their
`directives.txt` file, have been changed to use
`test-also=--wasm-compiler=optimizing;`.
In places where the JSContextOptions are set, the non-selected compiler (Ion
or CL) is explicitly set to `false` (eg, `.setWasmIon(false)`). This may be
overly conservative, but seems wise given that it's not immediately obvious
what the previous value of that flag is, and given the recent difficulties
with incorrect option propagation/handling (eg, bug 1697560).
Differential Revision: https://phabricator.services.mozilla.com/D101695
Loading cached shaders with glProgramBinary fails consistently for all
but the most trivial of our shaders on Adreno 3xx, so caching and
attempting to load them is a waste of time. Chromium and other
projects also appear to have disabled their shader caches on Adreno
3xx due to bugs.
This patch moves the gfx.webrender.program-binary-disk pref
declaration from all.js to StaticPrefList.yaml. Rather than directly
using the value of the pref to decide whether to create the shader
cache, we now initialize a Feature in gfxConfigManager with a default
value from the pref and then configure it from the blocklist. On
Android we block the feature on Adreno 3xx devices. The pref remains
true by default on Android and Windows, and false by default on Linux
and Macos.
Differential Revision: https://phabricator.services.mozilla.com/D111427
This commit adds a declarative `JS_FOR_WASM_FEATURES` macro which
expands for every WebAssembly proposal we are gating. Most feature
gating code is refactored to use this macro so that we have one place
we need to change to get the majority of this code working. The only
place that needs to be updated for new features is the browser pref
declaration code, as that cannot use this macro. This is documented
in the new WasmFeatures.h header.
The feature gating logic should work almost identically as before.
The changes are:
* All browser prefs are moved to StaticPrefList.yaml
* The code to enable a feature was conditionally compiled to not
enable the feature at variously stages of the "flag-flow". Now
the only place that is conditionally compiled to not work is
in the WasmXFlag functions. This is to make the macro simpler
and might be able to be reverted if need be.
* The flag for gc is shortened from gcTypes to gc so that the
existing usages of the wasmGcEnabled shell function don't have
to change.
This commit also has the effect of giving function-references/gc/
exception-handling a proper browser pref for enabling the features.
Differential Revision: https://phabricator.services.mozilla.com/D110820
For webcompat reasons, we have determined that we should only limit the length
of URIs in specific cases. We're going to handle this on the GV side instead.
Differential Revision: https://phabricator.services.mozilla.com/D109426
Flip javascript.options.wasm_simd to true for beta and release.
This patch leaves the flag as true on nightly and otherwise false, for arm64,
since arm64 code landing is imminent. But in truth simd is not even compiled
in for arm64 at the moment.
Differential Revision: https://phabricator.services.mozilla.com/D111285
The patches on this bug make bug 1684441 increase in frequency. Presumable ASAN
shutdown is in many cases already close to the timeout, and this bug is making
it trip over the edge.
A 4 minute timeout made a broad linux x64 ASAN try run go from five occurrences
of bug 1684441 to two, whereas a 5 minute timeout made them go to zero.
Differential Revision: https://phabricator.services.mozilla.com/D109785
Similifies use of EventStates and ObjectType/FallbackType enums since most states they represented are no longer valid with the removal of NPAPI plugins. The state machine for (unsupported) plugin elements is now much simpler but still distinguishes between HTML fallbacks, fallbacks leading to a "BROKEN" state (e.g. failing to load the image the element refers to), and fallbacks that would simply lead the element to occupy an empty region. The last type of fallback is behind a pref "layout.use-plugin-fallback" and is disabled by default.
Simplifying the state machine allows us to clean up nsObjectLoadingContent. We also update many of the enums which refered to plugins, which would otherwise get confusing.
Differential Revision: https://phabricator.services.mozilla.com/D107158
This makes the snapback less aggressive, and feels more like Safari to me.
Reducing the stiffness makes the animation take longer to complete.
To counteract the longer time, I've also reduced the damping a little bit;
reducing the damping makes the animation complete a little more quickly.
Depends on D110845
Differential Revision: https://phabricator.services.mozilla.com/D110846
This change constitutes a way we can redirect users to an actual page that
explains what captive portals are and why we are making these requests.
Normally users should not see this page, as we only compare the contents
of a small html file. The meta redirect only happens when loaded in a
page.
The SUMO URL https://support.mozilla.org/kb/captive-portal will automatically
redirect to the appropriate locale.
Differential Revision: https://phabricator.services.mozilla.com/D99773
This patch introduces a new way to way to schedule input tasks, such
that input tasks remain at `InputHigh` priority normally, however, when
there's a pending `Vsync` priority task in the task queue, we
increase the priority of input tasks from `InputHigh` to `InputHighest` to
rush processing the pending input tasks.
There are two restrictions to ensure we don't delay vsync too much:
- There's a hard limit duration
- We won't process the input tasks that are newly added after we've
started to process the current number of input tasks
Differential Revision: https://phabricator.services.mozilla.com/D109499
The patches on this bug make bug 1684441 increase in frequency. Presumable ASAN
shutdown is in many cases already close to the timeout, and this bug is making
it trip over the edge.
A 4 minute timeout made a broad linux x64 ASAN try run go from five occurrences
of bug 1684441 to two, whereas a 5 minute timeout made them go to zero.
Differential Revision: https://phabricator.services.mozilla.com/D109785
Similifies use of EventStates and ObjectType/FallbackType enums since most states they represented are no longer valid with the removal of NPAPI plugins. The state machine for (unsupported) plugin elements is now much simpler but still distinguishes between HTML fallbacks, fallbacks leading to a "BROKEN" state (e.g. failing to load the image the element refers to), and fallbacks that would simply lead the element to occupy an empty region. The last type of fallback is behind a pref "layout.use-plugin-fallback" and is disabled by default.
Simplifying the state machine allows us to clean up nsObjectLoadingContent. We also update many of the enums which refered to plugins, which would otherwise get confusing.
Differential Revision: https://phabricator.services.mozilla.com/D107158
No reason that code needs to be there. The findbar modal highlight stuff is not
being worked on and it was unclear to me why it needed a fission check, so I
removed that special case. The findbar code can customize the colors with
Selection.setColors anyways, which is a better fix.
Depends on D110673
Differential Revision: https://phabricator.services.mozilla.com/D110674
This is a follow-up that I thought was worth doing, but let me know if
you disagree or what not. I think this produces the best results:
* For light pages, we still get light scrollbars for the track, but the
active thumb still uses the dark theme highlight color.
* For dark pages, we again still use the themed highlight color for the
thumb, and we use dark scrollbar colors elsewhere like we do now.
Again, let me know if you think this is not worth it, or is too much, or
what not. I've tested this on a decent range of popular GTK themes and
it looks like a clear progression to me.
Differential Revision: https://phabricator.services.mozilla.com/D110203
Selection and accent color should be uncontroversial, since we ensure
the darker variant goes in the background, and the scrollbars were
intended to get passed from the parent theme in bug 1669368, but it was
regressed by the initial RemoteLookAndFeel work.
Differential Revision: https://phabricator.services.mozilla.com/D110175
This patch adds an expiration tracker to decide when to unmap unused
shared surfaces from our address space to reclaim virtual memory. This
is only used on 32-bit builds of Firefox where there is meaningful
virtual address space pressure.
Differential Revision: https://phabricator.services.mozilla.com/D109440
The only known brokeness with ICCv4 is bug 1555331 and
that only applies to parametric output profiles which no longer
applies to macOS because we always use sRGB there now.
Differential Revision: https://phabricator.services.mozilla.com/D110034
This patch adds an expiration tracker to decide when to unmap unused
shared surfaces from our address space to reclaim virtual memory. This
is only used on 32-bit builds of Firefox where there is meaningful
virtual address space pressure.
Differential Revision: https://phabricator.services.mozilla.com/D109440
This patch adds an expiration tracker to decide when to unmap unused
shared surfaces from our address space to reclaim virtual memory. This
is only used on 32-bit builds of Firefox where there is meaningful
virtual address space pressure.
Differential Revision: https://phabricator.services.mozilla.com/D109440
This change constitutes a way we can redirect users to an actual page that
explains what captive portals are and why we are making these requests.
Normally users should not see this page, as we only compare the contents
of a small html file. The meta redirect only happens when loaded in a
page.
The SUMO URL https://support.mozilla.org/kb/captive-portal will automatically
redirect to the appropriate locale.
Differential Revision: https://phabricator.services.mozilla.com/D99773
Instead of collecting data from the entire tree of documents, we
collect data per document. The collected data is sent to the
corresponding parent window context and is applied incrementally to
the tab state cache.
Differential Revision: https://phabricator.services.mozilla.com/D107814
This way, tests which specifically want to test overscroll can set the
pref explicitly, and other tests need not worry about accidentally
going into overscroll.
Differential Revision: https://phabricator.services.mozilla.com/D109435
Actually the page in this case starts getting styled _after_ the load
event, sometimes, but when that happens that also causes a white flash
in other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D109392
Instead of collecting data from the entire tree of documents, we
collect data per document. The collected data is sent to the
corresponding parent window context and is applied incrementally to
the tab state cache.
Differential Revision: https://phabricator.services.mozilla.com/D107814
- Add missing include directives and forward declarations.
- Remove some extra include directives.
- Add missing namespace qualifications.
- Move include directives out of namespace in toolkit/xre/GlobalSemaphore.h
Differential Revision: https://phabricator.services.mozilla.com/D98894
This is macOS only and behind the prefs widget.macos.native-context-menus and
browser.proton.contextmenus.enabled .
The big design question here is: Where do we put the fork in the road? How much
should the existing non-native popup management machinery know about the state
of the native menu? Which parts of the non-native state should a) reflect the
true native state, b) enter a special "handled natively" state, or c) lie?
This patch picks the following approach:
- The nsMenuPopupFrame of the root menupopup knows about the native menu; it
keeps it alive in its new mNativeMenu field.
- If the context menu has submenus, i.e. nested <menupopup> elements, the
nsMenuPopupFrames for those nested menupopups do not know anything about the
native menu.
- The mPopupState of natively-handled nsMenuPopupFrames is ePopupClosed.
- XULPopupElement::GetState, which queries the frame's mPopupState, also
returns "closed". This might cause problems in the future.
- The XUL popup manager's mPopups "menu chain" does not know about any open
native menus.
- The rollup widget also does not know about the native popup.
I've chosen to use ePopupClosed for native menus for the following reasons:
1. While mirroring / updating the state for the root menu would be doable
without too much trouble, it would be much more annoying to do the same for
nested menupopups of submenus. So if submenus will be ePopupClosed, it's
consistent for the root menu to also be ePopupClosed.
2. nsXULPopupManager has assertions (for example in MayShowPopup) that make
sure that the menu popup frame's mPopupState is consistent with the XUL
popup manager's mPopups menu chain. Keeping the two both "closed" is the
easiest way to achieve consistency.
Unless there are grave concerns with this approach, I suggest we go with it for
now and see what trouble arises.
Differential Revision: https://phabricator.services.mozilla.com/D109183
Actually the page in this case starts getting styled _after_ the load
event, sometimes, but when that happens that also causes a white flash
in other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D109392
The backend CompositorD3D11/CompositorOGL layers compositors can already do
partial clear optimizations for us if applicable. The only thing we need to
do is pass in the actual dirty/opaque regions so that it can utilize it.
Like with RenderCompositorSWGL, we move the actual allocation of the framebuffer
into StartCompositing when this information is known, rather than BeginFrame
which is too early in the frame to have this information yet.
Differential Revision: https://phabricator.services.mozilla.com/D109092
This lets the WindowServer do all of the color correction for us
including WebGL and 2D canvas.
There's some concern that this will increase GPU usage as
reported in https://bugs.chromium.org/p/chromium/issues/detail?id=417150#c34.
However, the alernative of doing everything in device space isn't very
attractive because we'd have to color manage canvas and webgl ourselves.
Further, Chrome doesn't seem to be using the device space and it seems
like there's typically already a mix of color spaces in use so hopefully
the GPU increase is not high.
Differential Revision: https://phabricator.services.mozilla.com/D109383
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
Note that this removes `window.ondeviceproximity` and `window.onuserproximity` which unexpectedly have been exposed unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D109160
UIS_INITIALIZE does something like setting the flag if the last input event was
a mouse event or clearing it if it was a keyboard event. Unfortunately, if this
is initialized to always show focus rings we start always showing outlines for
all content, all the time, which is both undesired and confusing.
It's also not clear from the docs _which_ event it looks at specially at
startup, but anyhow the result we get is clearly flaky, from my testing.
Explicitly clear the flag. It's not clear to me if other applications can cause
the state to change... but otherwise maybe we can just remove the code dealing
with these flags?
Differential Revision: https://phabricator.services.mozilla.com/D109086
- 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
Butkovits Atila
Matthew Gaudet
Emilio Cobos Álvarez
Dragana Damjanovic
Olli Pettay
Valentin Gosu
Narcis Beleuzu
Chris Martin
Kershaw Chang
Jan Varga
Jeff Muizelaar
Kagami Sascha Rosylight
Alexandru Michis
Sean Feng
Robert Mader
Csoregi Natalia
Markus Stange
Brindusan Cristian
Christoph Kerschbaumer
Tom Schuster
Agi Sferro
Chris Fallin
Dorel Luca
Jon Bauman
Paul Adenot
Mark Striemer
Noemi Erli
Sarah Ukoha
Botond Ballo
Timothy Nikkel
Gijs Kruitbosch
Julian Seward
Andrew Osmond
Edgar Chen
Boris Chiou
Jonathan Kew
Eugen Sawin
Morgan Reschenberg
Lars T Hansen
Jamie Nicol
Mike Conley
Aaron Klotz
Ryan Hunt
Marco Bonardo
Cosmin Sabou
Ryan VanderMeulen
Yulia Startsev
Bernard Igiri
smolnar
Martin Thomson
Andreas Pehrson
David Parks
stransky
Caroline Cullen
Tom Tung
Dan Minor
Harry Twyford
Tim Huang
Bogdan Tara
Andreas Farre
sotaro
Simon Giesecke
Tim Giles
Lee Salzman
Emily McDonough
Brendan Dahl
Nihanth Subramanya
Dimi Lee
Ted Campbell
Kris Maglione
sagudev
Gerald Squelart