`nsRange` instances are allocated a lot in the heap especially by editor and
spellchecker. The allocation cost is too bad for benchmarks. Therefore,
we should reuse released instances as far as possible. For managing it in
static factory methods of `nsRange`, we need to hide `nsRange` constructor.
Differential Revision: https://phabricator.services.mozilla.com/D61237
--HG--
extra : moz-landing-system : lando
LayoutFrameType::NumberControl is unused, and nsNumberControlFrame inherits now
from nsTextControlFrame. There are three places that check for
LayoutFrameType::TextInput. Two direct ones:
* ShouldApplyOverflowCLipping
* nsFontInflationData
And one indirect via IsTextInputFrame, the one mentioned in comment 2. For all
those three, it makes sense for nsNumberControlFrame to be handled in the same
way as nsTextControlFrame.
Long term we may want to get rid of the concept of frame types and just use
queryFrame or some sugar of that sort, as it's error prone. But for now this
fixes the bug.
Differential Revision: https://phabricator.services.mozilla.com/D61088
--HG--
extra : moz-landing-system : lando
It's possible that UpdateDynamicTollbarOffset is called repeatedly before we
actually fire a window resize event.
Differential Revision: https://phabricator.services.mozilla.com/D60812
--HG--
extra : moz-landing-system : lando
Per SVG2 spec, the EBNF allows the path data string to be empty.
An empty path data string disables rendering of the path.
Therefore, we should make path('') a valid path string.
The related spec issue: https://github.com/w3c/fxtf-drafts/issues/392.
Now we serialize `path("")` as `path("")` for offset-path and clip-path.
Differential Revision: https://phabricator.services.mozilla.com/D60771
--HG--
extra : moz-landing-system : lando
"Scripts" wasn't making any sense for this marker and it was nearly imposssible
to understand. It should be "requestAnimationFrame callbacks" instead.
Differential Revision: https://phabricator.services.mozilla.com/D60229
--HG--
extra : moz-landing-system : lando
Consider the following scenario:
1. Select a word in an iframe.
2. Select a word in the parent document. (The carets in iframe hide
due to blur, but the selection is still there.)
3. Scroll the parent document.
The selection in the iframe (made in step 1) has a non-collapsed range.
Thus the carets show again after scrolling due to `UpdateCarets()`
called in the end of `AccessibleCaretManager::OnScrollEnd()`.
To fix the dual AccessibleCaret in the same page (described in bug
1199967), we can simply show no carets if the window is not focused.
This behavior matches Google Chrome on Android.
Differential Revision: https://phabricator.services.mozilla.com/D52768
--HG--
extra : moz-landing-system : lando
Long-pressing on a text in an unfocused iframe to select a word never
works. Currently, you need to single tap to focus the iframe first.
Each PresShell has an associated AccessibleCaretEventHub. This patch
fixes this bug by routing the event to the AccessibleCaretEventHub under
the event point, and handle it there. If the event is not handled, then
we handle it by the focused AccessibleCaretEventHub as before.
I've experimented with only routing the event to the
AccessibleCaretEventHub under the event point, without routing to the
fallback focused AccessibleCaretEventHub. However, caret dragging didn't
work in iframes. I didn't debug further.
Differential Revision: https://phabricator.services.mozilla.com/D52767
--HG--
extra : moz-landing-system : lando
We need the resolution to be restored when and if the presshell creates
a MobileViewportManager. That decision happens in
PresShell::UpdateViewportOverridden. In order for the resolution to be
saved somewhere it has to exist outside the presshell itself, since
the presshell will be destroyed and recreated during some of the
operations that also destroy the MVM -- such as closing the devtools'
Responsive Design Mode. So Document holds this resolution and gets
accessor methods to allow the presshell to get and set that resolution
as needed.
Differential Revision: https://phabricator.services.mozilla.com/D59821
--HG--
extra : moz-landing-system : lando
It removes a script blocker. Therefore, although it depends on the caller
whether it causes running script or not. However, we should mark it as
`MOZ_CAN_RUN_SCRIPT` for safer code.
It's called only by the destructor of `nsAutoCauseReflowNotifier`. Therefore,
this patch also marks its constructor as `MOZ_CAN_RUN_SCRIPT` for making
each creator method marked as `MOZ_CAN_RUN_SCRIPT` or
`MOZ_CAN_RUN_SCRIPT_BOUNDARY`.
Most of the creators is mutation listener methods. However, `PresShell`
does nothing after destroying `nsAutoCauseReflowNotifier`. Therefore,
this patch does not change the callers in MutationObserver.cpp to use
`RefPtr<PresShell>` at calling them because changing it may cause performance
regression.
Perhaps, we should create another methods of `WillCauseReflow()` and
`DidCauseReflow()` to avoid unnecessary `MOZ_CAN_RUN_SCRIPT` marking.
However, I'm not sure whether most callers may run script or not because
of outside of my knowledge.
Differential Revision: https://phabricator.services.mozilla.com/D55805
--HG--
extra : moz-landing-system : lando
Consider the following scenario:
1. Select a word in an iframe.
2. Select a word in the parent document. (The carets in iframe hide
due to blur, but the selection is still there.)
3. Scroll the parent document.
The selection in the iframe (made in step 1) has a non-collapsed range.
Thus the carets show again after scrolling due to `UpdateCarets()`
called in the end of `AccessibleCaretManager::OnScrollEnd()`.
To fix the dual AccessibleCaret in the same page (described in bug
1199967), we can simply show no carets if the window is not focused.
This behavior matches Google Chrome on Android.
Differential Revision: https://phabricator.services.mozilla.com/D52768
--HG--
extra : moz-landing-system : lando
Long-pressing on a text in an unfocused iframe to select a word never
works. Currently, you need to single tap to focus the iframe first.
Each PresShell has an associated AccessibleCaretEventHub. This patch
fixes this bug by routing the event to the AccessibleCaretEventHub under
the event point, and handle it there. If the event is not handled, then
we handle it by the focused AccessibleCaretEventHub as before.
I've experimented with only routing the event to the
AccessibleCaretEventHub under the event point, without routing to the
fallback focused AccessibleCaretEventHub. However, caret dragging didn't
work in iframes. I didn't debug further.
Differential Revision: https://phabricator.services.mozilla.com/D52767
--HG--
extra : moz-landing-system : lando
There is no way this ever properly worked, as we always passed null for
`aFrameState`.
So it'd only work if we reframed the document element or such... Which is not
amazing.
For simpler test-cases, when we don't construct the scrollframe via
PresShell::Initialize, but via the regular frame constructor updates
(ContentAppended, etc...), those end up working because we go through lazy frame
construction, which ends up in RecreateFramesForContent, which passes
mTempFrameTreeState.
Differential Revision: https://phabricator.services.mozilla.com/D59569
--HG--
extra : moz-landing-system : lando
On webrender on android, parent-process pages (eg about:support) were not being
rendered immediately after minimising then resuming the app, resulting in a
black screen. The problem was that webrender believed the previous frame was
still valid, and therefore that it did not need to render a new
one. Content-process pages were unnaffected because we clear cached resources
when the app is minimised, so we accidentally rendered a new frame on
resumption.
To fix this we always force a new frame to be rendered immediately on
resumption. This uncovers a race condition which causes us to sometimes render
frames at the wrong size when the window size has changed (for example when
showing or hiding the keyboard), so that is also fixed.
This also fixes a bug affecting fenix, where when opening a page in a new tab
the portion of the screen where the keyboard used to be would remain black until
the page had loaded. This no longer occurs because we force a composite as soon
as the keyboard is hidden.
Additionally, this patch reverts the original attempt at fixing this
bug, as it is not necessary.
Differential Revision: https://phabricator.services.mozilla.com/D59367
--HG--
extra : moz-landing-system : lando
Tim Nguyen
Tetsuharu OHZEKI
Thomas Dolezal
Narcis Beleuzu
Eric Rahm
Masayuki Nakano
Miko Mynttinen
Kousuke Takaki
Cosmin Sabou
Emilio Cobos Álvarez
Hiroyuki Ikezoe
Boris Chiou
Bogdan Tara
tichnas
Sylvestre Ledru
Jamie Nicol
Nazım Can Altınova
Ting-Yu Lin
Brad Werth
Noemi Erli
Julian Descottes
Mirko Brodesser
Brindusan Cristian
Sebastian Streich