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
Mark Striemer
Cosmin Sabou
Noemi Erli
Andrew Osmond
Butkovits Atila
Valentin Gosu
Andreas Farre
Botond Ballo
Emilio Cobos Álvarez
sotaro
Bogdan Tara
Tom Tung
Simon Giesecke
Tim Giles
Jonathan Kew
Markus Stange
smolnar
Lee Salzman
Jeff Muizelaar
Emily McDonough
Kagami Sascha Rosylight
Dragana Damjanovic
Kershaw Chang
Harry Twyford