We don't line-break after a hyphen when it occurs between numerals, like in page or date ranges,
preferring to keep the range together as a unit when wrapping text.
However, if the available space is very narrow, e.g. in a small table cell, this may lead to
undesirable overflow. So to try and avoid this, this patch allows an "emergency" line-break
opportunity (similar to what `overflow-wrap: break-word` would do) after the hyphen in such
a case.
This affects a number of existing reftests, but the changes in behavior make us more like
WebKit/Blink (which generally allow a break after hyphen between numerals) in these cases,
so it seems unlikely to lead to webcompat issues; rather, it will help with existing issues
where people assume the content can wrap.
Differential Revision: https://phabricator.services.mozilla.com/D197936
UnregisterTextureOwner, if called before any use of UseRemoteTexture, can cause UseRemoteTexture to wait
for the texture owner to be created, since the texture owner does not exist, and there is no evidence it
was previously unregistered.
This patch attempts to address the issue by delaying the actual UnregisterTextureOwner until all such
UseRemoteTexture instances are processed. This is accomplished by noting that UseRemoteTexture ops come
in via transactions from a CompositableForwarder and so all are associated with a forwarder transaction
with a FwdTransactionId. RecordedTextureData on destruction reports the last FwdTransactionId associated
with its final UseRemoteTexture before it attempts to call UnregisterTextureOwner. If RemoteTextureMap
has not been notified of a given FwdTransactionId yet, then the UnregisterTextureOwner call will be
deferred until it has seen this FwdTransactionId.
This adds a RemoteTextureTxnScheduler to track the issuing of dependencies and waiting for FwdTransactionIds.
This patch also cleans up the issuing of FwdTransactionIds themselves to be associated with a given
top-level protocol so that all sub-protocols have transaction numbers that can be safely compared amongst
each other. This makes dependency expiration more robust since any advancement of the transaction number
from any source can help retire expired dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D197895
UnregisterTextureOwner, if called before any use of UseRemoteTexture, can cause UseRemoteTexture to wait
for the texture owner to be created, since the texture owner does not exist, and there is no evidence it
was previously unregistered.
This patch attempts to address the issue by delaying the actual UnregisterTextureOwner until all such
UseRemoteTexture instances are processed. This is accomplished by noting that UseRemoteTexture ops come
in via transactions from a CompositableForwarder and so all are associated with a forwarder transaction
with a FwdTransactionId. RecordedTextureData on destruction reports the last FwdTransactionId associated
with its final UseRemoteTexture before it attempts to call UnregisterTextureOwner. If RemoteTextureMap
has not been notified of a given FwdTransactionId yet, then the UnregisterTextureOwner call will be
deferred until it has seen this FwdTransactionId.
This adds a RemoteTextureTxnScheduler to track the issuing of dependencies and waiting for FwdTransactionIds.
This patch also cleans up the issuing of FwdTransactionIds themselves to be associated with a given
top-level protocol so that all sub-protocols have transaction numbers that can be safely compared amongst
each other. This makes dependency expiration more robust since any advancement of the transaction number
from any source can help retire expired dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D197895
helper_zoomToFocusedInput_nested_position_fixed.html is a test case for bug
1627734 that zoomToFocusedInput doesn't reset the root scroll position to the top.
helper_zoomToFocusedInput_zoom_in_position_fixed.html is a test case that
zoomToFocusedInput zooms into an element in position:fixed subtree.
Differential Revision: https://phabricator.services.mozilla.com/D197281
The scrollend event has been content enabled by default for about a
year. Remove the preference that allows the feature to be chrome-only.
Differential Revision: https://phabricator.services.mozilla.com/D197699
This patch makes it so that if we encounter an issue launching the GPU
process, we attempt to fallback first over disabling the GPU process.
This is because the different acceleration modes we might start with
change how we initialize. It may be possible to have a pure Software
WebRender GPU process with a given users configuration.
Differential Revision: https://phabricator.services.mozilla.com/D197827
This is preparation for Bug 1868927.
By deferring ApplyAsyncImageForPipeline() for TextureHost in AsyncImagePipeline of synchronous WebRenderImageHost, ApplyAsyncImageForPipeline() can be called after the RemoteTextureHostWrapper is in the ready state.
Differential Revision: https://phabricator.services.mozilla.com/D197320
When we encounter an excessive number of device resets in the GPU
process, we would previously just disable the GPU process over blaming
the acceleration itself. Now we either restart the GPU process in a
last ditch attempt to clear the device state, and failing that, disable
acceleration due to excessive resets.
Differential Revision: https://phabricator.services.mozilla.com/D197721
Firefox should be more stable with the GPU process and software
rendering than doing software rendering in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D197714
Checking the fonts in HelveticaNeue.ttc on macOS Sonoma, both HelveticaNeue-Medium and -MediumItalic have the same weight (500) in their OS/2 table, and return the same value (0.23) for their kCTFontWeightTrait. Back in bug 931426 when the weight override pref was added, we were getting different weights from appKit for these two "Medium" faces, but that no longer appears to be an issue.
This patch makes our CoreTextWeightToCSSWeight mapping a bit more sophisticated, with the added data point of CSS/OpenType weight 500 = CoreText weight 0.23, which we're seeing here in HelveticaNeue. With this refinement in the mapping, we can drop the old override for the HelveticaNeue-MediumItalic face.
Differential Revision: https://phabricator.services.mozilla.com/D197665
It's wasteful to call DrawTargetWebgl::BeginFrame if we're locking in a read-only mode. It may
also mess up DrawTargetWebgl's internal profiling if we count a read-only use as an actual frame.
Differential Revision: https://phabricator.services.mozilla.com/D197483
The idea of trying to obsolete the presented texture from the last frame when
creating a new texture, if we believe it wasn't used, seems problematic and
may not actually address the fundamental issue at hand.
It seems more like there are use-cases where the recorded texture is locked
and unlocked many times in succession, whereas we actually only intend to
present it once.
This decouples the TextureLock/TextureUnlock events from a new PresentTexture
event which handles the actual creation of remote texture ids, so that regardless
of how many times we lock/unlock the recorded texture, we don't actually churn
presentation unless we truly need to. This seems like a better way of addressing
the memory reuse issue than trying to remove textures since we don't create them
in the first place.
Differential Revision: https://phabricator.services.mozilla.com/D197453
This is preparation for Bug 1868927.
By deferring ApplyAsyncImageForPipeline() for TextureHost in AsyncImagePipeline of synchronous WebRenderImageHost, ApplyAsyncImageForPipeline() can be called after the RemoteTextureHostWrapper is in the ready state.
Differential Revision: https://phabricator.services.mozilla.com/D197320
It looks like this was an oversight in bug 1155059, that in one place an
already_AddRefed does not get converted to a RefPtr.
Differential Revision: https://phabricator.services.mozilla.com/D197374
While the assert is well-intentioned, it is mostly just causing more problems
than it solves. Due to the nature of shutdown, are in a partially shutdown state
where sCanvasRenderThread goes away, even though the CanvasRender thread still
exists and is processing the last events in the queue. Because of this, the assert
fails, even though we are actually on the correct thread. It seems reasonable here
to just remove the assert in FinishShutdown, since ActorDestroy already verifies
we are on the correct thread.
Depends on D197374
Differential Revision: https://phabricator.services.mozilla.com/D197375
While the assert is well-intentioned, it is mostly just causing more problems
than it solves. Due to the nature of shutdown, are in a partially shutdown state
where sCanvasRenderThread goes away, even though the CanvasRender thread still
exists and is processing the last events in the queue. Because of this, the assert
fails, even though we are actually on the correct thread. It seems reasonable here
to just remove the assert in FinishShutdown, since ActorDestroy already verifies
we are on the correct thread.
Depends on D197374
Differential Revision: https://phabricator.services.mozilla.com/D197375
Moving to a FIFO queue means that textures that were just pushed into the recycling
queue will be reused last, reducing the amount of possible lock contention.
Differential Revision: https://phabricator.services.mozilla.com/D197291
ALLOC_MANUAL_SYNCHRONIZATION could be used only when ID3D11Texture2D is allocated by compositor device. But canvas device is not compositor device.
Differential Revision: https://phabricator.services.mozilla.com/D197276
It seems that locking has side-effect other than synchronization for
some backends, such as mapping data into readable/writeable memory. We
need to leave the lock calls in place, but so long as we leave
ALLOC_MANUAL_SYNCHRONIZATION in place for D2D, we will avoid created
a KeyedMutex which should still avoid synchronization overheads.
Meanwhile, incidental finding that a bug was caused by 1861605,
meaning KeyedMutexes stopped getting properly initialized in any case.
This fixes that too.
Differential Revision: https://phabricator.services.mozilla.com/D197271
When we use a TextureData instead of a DrawTargetWebgl, we manually register a remote
texture owner on CanvasTranslator's RemoteTextureOwnerClient. Unlike DrawTargetWebgl,
this client will stick around after the texture info goes away, so we need to also
manually unregister it when removing a texture id.
Differential Revision: https://phabricator.services.mozilla.com/D197264
Narcis Beleuzu
Jonathan Kew
Lee Salzman
Sandor Molnar
Jeff Muizelaar
Hiroyuki Ikezoe
Natalia Csoregi
Nika Layzell
Dan Robertson
sotaro
Andrew Osmond
Timothy Nikkel
Nicolas Silva
Kelsey Gilbert
serge-sans-paille
Iulian Moraru
Calixte
Cristian Tuns
Cosmin Sabou
Norisz Fay
Makoto Kato