From macOS Catalina, Hiragino Kaku Gothic ProN and etc aren't instaleld with
clean install. And default sans-serif font for Japanese is Hiragino Sans.
Differential Revision: https://phabricator.services.mozilla.com/D97900
To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.
The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.
IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.
While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. When using PVsync, limit updates to once in every
250ms in order to minimize overhead while still updating fast.
How to test:
- run the Wayland backend
- enable `widget.wayland_vsync.enabled`
- optionally: disable `privacy.reduceTimerPrecision`
- run `vsynctester.com` or `testufo.com`
Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz
Original patch by Kenny Levinsen.
Differential Revision: https://phabricator.services.mozilla.com/D93173
To allow `requestAnimationFrame()` and similar things to run at monitor
speed if there is only a window-specific vsyncsource available.
This is the case for Wayland and, in the future, EGL/X11. Other backends
may opt for window specific vsyncsources as well at some point.
The idea is to, instead of using global vsync objects, expose a vsyncsource
from nsWindow and use it for refresh drivers. For the content process, move
VsyncChild to BrowserChild, so for each Browserchild there is only one
VsyncChild to which all refresh drivers connect.
IPC in managed either by PBrowser or PBackground. Right now, PBrowser is
only used on Wayland, as both PBrowser and the Wayland vsyncsource run
on the main thread. Other backends keep using the background thread for
now.
While at it, make it so that we constantly update the refresh rate. This
is necessary for Wayland, but also on other platforms variable refresh rates
are increasingly common. When using PVsync, limit updates to once in every
250ms in order to minimize overhead while still updating fast.
How to test:
- run the Wayland backend
- enable `widget.wayland_vsync.enabled`
- optionally: disable `privacy.reduceTimerPrecision`
- run `vsynctester.com` or `testufo.com`
Expected results:
Instead of fixed 60Hz, things should update at monitor refresh rate -
e.g. 144Hz
Original patch by Kenny Levinsen.
Differential Revision: https://phabricator.services.mozilla.com/D93173
This also implements an improved error message:
> TypeError: RegExp.prototype.global getter called on non-RegExp object: Math
This is similar to Chromes' message:
> RegExp.prototype.global getter called on non-RegExp object
Differential Revision: https://phabricator.services.mozilla.com/D95837
Partial fix.
If nsDisplayItem::RestoreState changes the state of an nsDisplayItem, that
invalidates any prior RetainedItems items sent to WebRender for it, and its
DisplayItemCache entry is invalid. Clear the cache index in the
nsDisplayItem.
RetainedDisplayListBuilder::PreProcessDisplayList doesn't have convenient access
to the DisplayItemCache, so don't clear the cache entry in the DisplayItemCache.
The cache itself will eventually realize the entry is unused and clear it.
Differential Revision: https://phabricator.services.mozilla.com/D97538
Implements the changes from the "has consensus" PR <https://github.com/tc39/ecma402/pull/471>.
The second pair of `DefaultNumberOption()` calls was inlined, because only the
fallback case is relevant anyway. Steps 12.d and 12.e from the spec PR were
combined into a single `if`-block. That way it also matches step 12.f more
closely.
Also changed the single `if` steps into an `if-else if` chain, because the
steps are mutually exclusive.
Depends on D95734
Differential Revision: https://phabricator.services.mozilla.com/D95735
The RDD process can no longer work without having access to win32k ; enabling this pref would lead to a crash on Nightly and failure to work elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D97753
Usually, IME sets selection and considers candidate list position at starting
new composition. However, Apple Japanese IME sometimes consider the candidate
list position at retrieving the character rects before setting selection.
Therefore, we need to store last commit string's character rects, but don't
need to store it in long time because Kakutei-Undo is supported by Japanese
IMEs and they work only immediately after committing a composition. E.g.,
after moving caret, it won't be available.
Depends on D97838
Differential Revision: https://phabricator.services.mozilla.com/D97839
Currently, it manages the composition start offset with `uint32_t` and setting
it to `UINT32_MAX` when there is no composition. But this is now rewritable
with `Maybe<uint32_t>` for easier to read.
Differential Revision: https://phabricator.services.mozilla.com/D97838
E.g. Blitting 1,1,-1,-1 to 0,2,2,0.
Some drivers have trouble with this.
Primarily tested by:
* conformance2/rendering/blitframebuffer-filter-outofbounds.html
* conformance2/rendering/blitframebuffer-outside-readbuffer.html
Differential Revision: https://phabricator.services.mozilla.com/D97890
This commit adds a rosetta status to three different places:
- `nsSystemInfo`, to check for rosetta status per apple specifications. We also use the same check in `nsCocoaFeatures` in D89961.
- `Troubleshoot.jsm`, to add rosetta status data (should it exist) to use in about:support
- `About:Support` itself, if the device is running MacOS
Differential Revision: https://phabricator.services.mozilla.com/D94930
The fade-out animation is kept.
To work around the bug, the first paint of the panel window needs to be done at
full window opacity. Reducing the window opacity after the shadow has been
computed works correctly.
Differential Revision: https://phabricator.services.mozilla.com/D97863
longsonr
Makoto Kato
Narcis Beleuzu
Robert Mader
Emilio Cobos Álvarez
Tom Schuster
Jeff Muizelaar
Dzmitry Malyshau
Jim Blandy
André Bargull
Jan Horak
Martin Stransky
Magnus Melin
Csoregi Natalia
Florent Viard
Christoph Kerschbaumer
Jean-Yves Avenard
Masayuki Nakano
Jeff Gilbert
Renovate Bot
championshuttler
Andrey Bienkowski
Sylvestre Ledru
Simon Giesecke
Kris Wright
Markus Stange
Mihai Alexandru Michis
Cristina Coroiu