The constructor of `nsPeekOffsetStruct` and `nsIFrame::GetFrameFromDirection`
take too many `bool` arguments. Therefore, adding new `bool` arguments does
not make sense. Now, we have a useful `mozilla:EnumSet` class to treat them
with an `enum class`. Therefore, let's change `nsPeekOffsetStruct` with it.
Differential Revision: https://phabricator.services.mozilla.com/D172758
It's called by `PeekOffsetFor*` and `GetPrevNextBidiLevels`, so it's used for
considering whether to put caret or move a selection range boundary.
Therefore, it should treat nodes which can be managed by `Selection` as
selectable. In theory, even if a native anonymous subtree does not have
an independent selection, its content nodes should not be the container of
the selection range boundaries of selection outside the subtree since
Selection API shouldn't expose nodes in native anonymous subtrees. Therefore,
it can simply treat content nodes in different anonymous subtrees are not
selectable.
Note that it's not standardized that how `Selection.modify` works with various
content nodes.
https://w3c.github.io/selection-api/#dom-selection-modify
And also Chrome cannot cross generated content like form controls with this API.
This could cause web-compat issues, but it does not make sense for caret
navigation, and anyway out of scope of this bug. Therefore, this patch just
adds the crash test.
Differential Revision: https://phabricator.services.mozilla.com/D172204
While Firefox builds for Android ARMv7 don't support non-NEON
processors, downstreams (including non-Android ones) may still want to
support them.
On the Firefox builds that don't support non-NEON processors, the NEON
flags are actually already passed globally, and they don't need to be
explicitly added. NEON_FLAGS is actually only meant to be used for
sources that specifically need NEON support even when the target doesn't
support it, for, e.g. specialized code behind runtime CPU detection.
So removing NEON_FLAGS is a no-op in practice when NEON processors are
already targeted.
Differential Revision: https://phabricator.services.mozilla.com/D172801
bg -> 01360f4bce126fd0758abb5759e8d88c809acd25
da -> b4c0357e5185526ae35a036310908bae02e97add
fr -> d95fa0593e2d0f5be54d2e5ab375ba85b39d4ba1
gn -> 6afafc4c9de1141ae87e63fe89e307e877f5b2c9
he -> 103f251af0aaee41278d9cc08085b431328562fa
hu -> d50652202be850d4e8df9d894828132059553835
ia -> ccf08deaa498f3e2491d7755f09651d3dae63bf5
is -> db0d33fcbe9a063a30ac28da1cd77f88a2218ec4
zh-CN -> 9ba36aef7f4fedbacc712c24ad4064b9565b6825
Highlights for this patch
- Support for the script overrides feature
- Overrides for html files are not supported
- Add styling to indicate overrides
- Add mochitests
Depends on D163600
Differential Revision: https://phabricator.services.mozilla.com/D163610
If the `.textContent` or `.defaultValue` attributes are used to change the content of a textarea,
according to the DOM Spec dictates first all children are removed and then a new child is added.
Removing all child elements must collapse the selection to 0.
However, the spec is not very precise on that matter,
see https://github.com/whatwg/html/issues/9028 .
This was currently not done (the selection was adjusted to the new length instead),
because the `Reset()` call was executed as a script runner,
therefore running (twice) after the new content has already been added.
With this change, the selection is adjusted to the new length explicitly
as soon as `ContentChanged()` is invoked, therefore updating it to 0
when content is removed.
Differential Revision: https://phabricator.services.mozilla.com/D172791
The a11y module wants to traverse frames in native anonymous subtrees.
Therefore, this patch adds new option for allowing it, makes
`nsIFrame::GetFrameFromDirection` check it before comparing native anonymous
subtree root nodes, and makes `HyperTextAccessible::FindOffset` use the
option.
Differential Revision: https://phabricator.services.mozilla.com/D172759
The constructor of `nsPeekOffsetStruct` and `nsIFrame::GetFrameFromDirection`
take too many `bool` arguments. Therefore, adding new `bool` arguments does
not make sense. Now, we have a useful `mozilla:EnumSet` class to treat them
with an `enum class`. Therefore, let's change `nsPeekOffsetStruct` with it.
Differential Revision: https://phabricator.services.mozilla.com/D172758
It's called by `PeekOffsetFor*` and `GetPrevNextBidiLevels`, so it's used for
considering whether to put caret or move a selection range boundary.
Therefore, it should treat nodes which can be managed by `Selection` as
selectable. In theory, even if a native anonymous subtree does not have
an independent selection, its content nodes should not be the container of
the selection range boundaries of selection outside the subtree since
Selection API shouldn't expose nodes in native anonymous subtrees. Therefore,
it can simply treat content nodes in different anonymous subtrees are not
selectable.
Note that it's not standardized that how `Selection.modify` works with various
content nodes.
https://w3c.github.io/selection-api/#dom-selection-modify
And also Chrome cannot cross generated content like form controls with this API.
This could cause web-compat issues, but it does not make sense for caret
navigation, and anyway out of scope of this bug. Therefore, this patch just
adds the crash test.
Differential Revision: https://phabricator.services.mozilla.com/D172204
This listens for some observer service notifications so we can re-fetch the
weather suggestion after wake and coming online, without having to wait for the
timer to fire. Please see the bug for background.
I changed the interval (repeating timer) to a timeout (non-repeating timer)
since the timer needs to be recreated on wake if the wake happens before the
start of the next fetch period.
Differential Revision: https://phabricator.services.mozilla.com/D172844
The a11y module wants to traverse frames in native anonymous subtrees.
Therefore, this patch adds new option for allowing it, makes
`nsIFrame::GetFrameFromDirection` check it before comparing native anonymous
subtree root nodes, and makes `HyperTextAccessible::FindOffset` use the
option.
Depends on D172758
Differential Revision: https://phabricator.services.mozilla.com/D172759
The constructor of `nsPeekOffsetStruct` and `nsIFrame::GetFrameFromDirection`
take too many `bool` arguments. Therefore, adding new `bool` arguments does
not make sense. Now, we have a useful `mozilla:EnumSet` class to treat them
with an `enum class`. Therefore, let's change `nsPeekOffsetStruct` with it.
Differential Revision: https://phabricator.services.mozilla.com/D172758
It's called by `PeekOffsetFor*` and `GetPrevNextBidiLevels`, so it's used for
considering whether to put caret or move a selection range boundary.
Therefore, it should treat nodes which can be managed by `Selection` as
selectable. In theory, even if a native anonymous subtree does not have
an independent selection, its content nodes should not be the container of
the selection range boundaries of selection outside the subtree since
Selection API shouldn't expose nodes in native anonymous subtrees. Therefore,
it can simply treat content nodes in different anonymous subtrees are not
selectable.
Note that it's not standardized that how `Selection.modify` works with various
content nodes.
https://w3c.github.io/selection-api/#dom-selection-modify
And also Chrome cannot cross generated content like form controls with this API.
This could cause web-compat issues, but it does not make sense for caret
navigation, and anyway out of scope of this bug. Therefore, this patch just
adds the crash test.
Differential Revision: https://phabricator.services.mozilla.com/D172204
`media.videocontrols.lock-video-orientation` uses deprecated mozLockOrientation
API and this API does nothing.
Fenix/android-component uses MediaSession API and its
`MediaSessionFullscreenFeature` sets screen orientation.
So it means that `media.videocontrols.lock-video-orientation` is unused and
unnecessary now. I would like to set false to avoid conflict of same feature
when toolkit/content/widgets/videocontrols.js implements screen orientation API.
Differential Revision: https://phabricator.services.mozilla.com/D172419
