Old NDK requires AKEYCODE defines for newer API version, but it is unnecessary
to define it when using NDK r20.
Differential Revision: https://phabricator.services.mozilla.com/D70786
--HG--
extra : moz-landing-system : lando
The toggle style was overridden in netmonitor for
no obvious reason, as the base styles take care of
everything we need.
Differential Revision: https://phabricator.services.mozilla.com/D71028
--HG--
extra : moz-landing-system : lando
Due to the include hell, `EditorBase.h` cannot include `EditorUtils.h`.
Therefore we need these 3 methods once. Additionally, `IsModifiableNode()`
is really odd method and looks like that it's used for the following 2 purposes:
1. Simply can be editable.
2. Can be removed from parent.
For the former case, we should sort out it with
`EditorUtils::IsEditableContent()`, but for now, this patch moves it to
`HTMLEditUtils::IsSimplyEditable()`. On the other hand, for the latter case,
we obviously has a bug. Therefore, this patch creates
`HTMLEditUtils::IsRemovableFromParentNode()` and make it check whether the
removing node is also editable.
Unfortunately, `EditorUtils::IsEditableContent()` needs to take editor type.
But it's most callers are in `HTMLEditor` and most of remains are in
common methods of `EditorBase`. I guess we could remove this ugly argument
in the future.
Depends on D70874
Differential Revision: https://phabricator.services.mozilla.com/D70875
--HG--
extra : moz-landing-system : lando
For now this generates just CACHE_IR_OPS and CACHE_IR_SHARED_OPS in CacheIROpsGenerated.h
but the plan is to use this to generate parts of the IR writer and compiler/transpiler
interface. The spewer could also potentially be improved now that each operand has a name
and more precise type.
Generating the IR writer will likely happen incrementally so that will give us
another chance to double check the precise types match what's in the YAML file.
Differential Revision: https://phabricator.services.mozilla.com/D70995
--HG--
extra : moz-landing-system : lando
Most other generated SpiderMonkey files have the 'Generated' suffix so let's
follow that convention.
Differential Revision: https://phabricator.services.mozilla.com/D70993
--HG--
extra : moz-landing-system : lando
`HTMLEditor::IsBlockNode()` is a virtual method derived from
`EditorBase::IsBlockNode()`. For the performance, `EditorBase`'s one just
return false for text node and `<br>` element. However, these check cost
is really cheap in these days. Therefore, we can make `TextEditor` also
use rich API.
This patch moves `HTMLEditor::NodeIsBlockStatic()` and
`HTMLEditor::NodeIsInlineStatic()` to `HTMLEditUtils`, and removes the wrapper
of the fommer, `HTMLEditor::IsBlockNode()` and `WSRunScanner::IsBlockNode()`.
Differential Revision: https://phabricator.services.mozilla.com/D70874
--HG--
extra : moz-landing-system : lando
Multiple issues here. The IsRangeVisible code was wrong, it was returning false
for ranges that were perfectly valid, but outside the viewport, because the
following piece of code:
if (!aMustBeInViewPort) {
// This is an early exit case because we don't care that that range
// is out of viewport, so we return that the range is "visible".
return true;
}
Was incorrectly after some stuff checking viewport visibility. This code is
pretty complex for no good reason, it wants to do something very
simple: Start from the visible selection if possible.
This patch still achieves this, using IsRangeRendered (which does a proper
hit-test to figure out if a range is in the viewport). Should have no behavior
differences except for non-collapsed ranges that are partially inside the
viewport.
Differential Revision: https://phabricator.services.mozilla.com/D71067
--HG--
extra : moz-landing-system : lando
We build the backdrop root only if the actual backdrop-filter computed
value has something relevant, so if the pref is changed the style will
change, the display list code doesn't need to do anything special.
This simplify enabling the property conditionally in other ways in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D71124
--HG--
extra : moz-landing-system : lando
We will ship all of the EXIF orientation related changes together in
this release.
Differential Revision: https://phabricator.services.mozilla.com/D70982
--HG--
extra : moz-landing-system : lando
This makes EXIF orientation metadata honored by default.
Introduce OrientedPixel and UnorientedPixel typed rects and sizes and
use them throughout RasterImage so that we don't confuse which we want.
The reason for doing this rather than having the imgLoader wrap every
RasterImage it creates with an OrientedImage is that returning the
wrapper messes with various notifications, as OrientedImage is not an
ImageResource.
(It would be even better if the JPEG decoder could decode to imgFrames
handling the EXIF orientation itself, but that's a more complicated
change.)
Differential Revision: https://phabricator.services.mozilla.com/D70273
--HG--
extra : moz-landing-system : lando
RasterImage will make use of them.
Note that there is one bug fix in this patch, which is that
OrientedImage::OrientSurface now creates a surface of the correct size.
(Previously this code was creating a surface with the underlying
image's size, rather than the correctly oriented size. But we must
not have been calling into that code with our current uses of
OrientedImage.)
Differential Revision: https://phabricator.services.mozilla.com/D70271
--HG--
extra : moz-landing-system : lando
We can modify the scroll position without invalidating the anchor (that's kind
of the point, actually).
So it's possible (and ok) to end up with a frame which is already maintaining
an anchor but for which CanMaintainAnchor now returns false.
So if you have a scrollframe with a non-zero scroll position and select an
anchor for that scrollframe, and then try to select an anchor for an ancestor,
you don't want to dig into there.
Differential Revision: https://phabricator.services.mozilla.com/D71103
--HG--
extra : moz-landing-system : lando
When an element with overflow:auto becomes scrollable, either by a style change or growing children, it should become focusable and fire a state change. Same in the inverse.
Differential Revision: https://phabricator.services.mozilla.com/D70561
--HG--
extra : moz-landing-system : lando
Changes to attributes such as disabled, contenteditable, and tabindex should cause FOCUSABLE
state changes to be fired when indeed the accessible gains or loses focusability.
Differential Revision: https://phabricator.services.mozilla.com/D70560
--HG--
extra : moz-landing-system : lando
For now, the local detection sucks. I will fix that once bug 1625884
is fixed
Differential Revision: https://phabricator.services.mozilla.com/D69683
--HG--
extra : moz-landing-system : lando
