CheckCurrentWord on content process causes sync IPC, so I would like to remove
this call on content process. New nsIEditorSpellChecker.suggest method can
avoid it.
Differential Revision: https://phabricator.services.mozilla.com/D119937
When getting suggestions from spellchecker's result, we use sync IPC
(`PRemoteSpellcheckEngine.CheckAndSuggest`). This is used by showing context
menu only on Gecko. So I think that we can remove this IPC if we add async API
to get spellchecker suggestions.
And in comm-central's code, `CheckCurrentWord` and `GetSuggestedWord` seems to
use on spellchecker dialog (content/dialogs/EdSpellCheck.js in mail and suite)
that runs on parent process. So c-c won't use this IPC method.
So I would like to add the promise version of getting spellchecker's
suggestion.
Differential Revision: https://phabricator.services.mozilla.com/D119936
Now, Gecko is the only browser to support undocumented `KeyEvent.initKeyEvent`.
We should drop it by default because `typeof KeyboardEvent.initKeyEvent` is
used at least in a major web-site and which causes not working the web-site.
Differential Revision: https://phabricator.services.mozilla.com/D121029
This takes the logic used for Image/CanvasLayer::ComputeEffectiveTransforms and uses it to get matching rendering for the Paint path.
Depends on D122175
Differential Revision: https://phabricator.services.mozilla.com/D122176
nsPresContext has a flag that caches the value of this pref, and the flag gets
updated in the next refresh driver tick after a pref-change occurs. Right now
we don't have a strong guarantee that the flag will have been updated by the
time the test assumes that it has, which is why we're seeing intermittent
failures.
This patch adjusts the test so that it waits for a double-rAF before proceeding
from its pref adjustment. I believe this is the recommended way of forcing &
waiting-out at least one refresh driver tick; and this should let the test
reliably assume the pref-adjustment has taken effect.
Differential Revision: https://phabricator.services.mozilla.com/D122169
This is useful so that author rules for :autofill also work for the
autofill preview.
It also makes the UA sheet in forms.css simpler (otherwise we'd need to
tweak the selectors to put :-moz-autofill-preview everywhere we put
:autofill).
Differential Revision: https://phabricator.services.mozilla.com/D122014
The style system uses the changed bits to compute the old state, so if
it's inaccurate it might cause styles to be incorrectly invalidated.
This causes issues because with the next patch the autofill jsm
calls removeManuallyManagedStates(AUTOFILL), then
addManuallyManagedStates(AUTOFILL | AUTOFILL_PREVIEW), and if the input
didn't have AUTOFILL before we'd incorrectly detect it as not changing
with the next patch.
Also make them not virtual anymore since nobody overrides them. An
alternative to this would be to assert that we don't yet have the state
we're adding (or that we have the state we're removing), and handle it
in the callers. But this is a bit more convenient.
Differential Revision: https://phabricator.services.mozilla.com/D122013
Move the extra_data to be a specific cache_data separate vec in
the display list payload.
This shouldn't change any functionality, but serves as a proof
of concept for future changes which will introduce several other
separated payload vectors.
Differential Revision: https://phabricator.services.mozilla.com/D121937
CachedBAxisMeasurement::mAscent caches the ascent of a flex item after
the measuring reflow, but the ascent may change after the final reflow
if the item is stretched and does some vertical alignment internally.
However, we don't cache the new ascent. Therefore, when we reflow the
item incrementally, if the CachedBAxisMeasurement::Key is valid, we just
skip the measuring reflow, and retrieve the wrong ascent from the cache.
Instead of fixing this bug by updating the cached ascent or rejecting
the ascent cache for a stretching flex item in block axis, this patch
removes the cache and sets ReflowOutput's BlockStartAscent() to the flex
item after the item's measuring reflow. (We've done the same after the
item's final reflow.) If the ascent is ReflowOutput::ASK_FOR_BASELINE,
we resolve in FlexItem::ResolvedAscent() anyway.
Differential Revision: https://phabricator.services.mozilla.com/D121404
Supplying a visibility rect to the display list builder when recording
an SVG image blob will allow the display list builder to trim out
unnecessary items and make the recordings smaller. This is particularly
important when we have an SVG image used as an atlas.
This patch also simplifies the call path for the recordings. This allows
us to avoid unnecessary clips and transforms and shrink the recording
further, as well as make the code more auditable.
Differential Revision: https://phabricator.services.mozilla.com/D122125
It's possible to observe an element in the iframe while the
ResizeObserver object lives in the outer document, so we have to make
sure we also schedule the observer for all documents in the same
BrowsingContext tree.
Differential Revision: https://phabricator.services.mozilla.com/D119843
Some platforms, especially mobile, don't allow setting the window
rect. The capabilities are supposed to say when that's possible or
not, so we shouldn't try to set it when we're told it's not.
Differential Revision: https://phabricator.services.mozilla.com/D121751
We can reuse most of the implementation from Firefox, we just need to
ensure that the corect android options end up in the capabilities.
Differential Revision: https://phabricator.services.mozilla.com/D121750
This attempts to emulate the behavior of GetRecommendedRenderingMode without
actually calling it. In addition, it allows some Gecko-specific behavior
like overriding the render mode explicitly that allows some simplification
of the decision-making.
Inside GetRecommendedRenderingMode, natural is only allowed if <= 20 size.
This allows us to thus decide mostly based on whether the size is > 20 or
if an explicit mode was specified. In the remaining case where we need
to check a GASP table if available, we defer to the symmetric flag. If
there is no GASP, we assume natural.
Differential Revision: https://phabricator.services.mozilla.com/D122025
This patch doesn't change behavior. The "InProcess" version of this API (which
we're migrating to in this patch) is used to annotate GetCrossDocParentFrame()
callsites that have been vetted as being OK with the fact that this API returns
null at the boundary of a cross-origin iframe, if fission is enabled.
The call that's being migrated here is about propagating the NS_FRAME_IN_POPUP
state-bit into subframes that are nested inside of a popup. This bit is used to
detect cases where the display root frame is different from the document frame.
We don't need to propagate the bit across process boundaries, because the child
process will have its own display root frame, distinct from that of the parent
process. So we're OK to use the "InProcess" version of the API here.
Differential Revision: https://phabricator.services.mozilla.com/D113546
The bug was that the tooltip was only being shown for reader-mode-button-icon. The tooltip would show if you hovered right over the icon, and it would be undefined otherwise. This patch shows the tooltip regardless of the hover target. The other items on nodeToTooltipMap and nodeToShortcutMap are toolbarbuttons, so their icons are added in CSS and event handling always sees the parent node as the hover target. The reader mode button icon, however, is an <image> child of its parent. Either it or its parent could be hover targets. I considered added some handling in GetDynamicShortcutTooltipText along the lines of checking node.closest(reader-mode-button). I settled on just adding more entries to nodeToTooltipMap and nodeToShortcutMap since it's safer and easier to uplift.
Differential Revision: https://phabricator.services.mozilla.com/D122126
This patch adds console message for disallowing relaxing default
referrer policy. The console message will only be reported if less
restricted policy has been set for cross-site requests. And it will use
different messages according to whether the restriction is enabled or
not.
Differential Revision: https://phabricator.services.mozilla.com/D121699