When selected text in `geckoview_example`, the text selection toolbar was always positioned in the top left corner of the screen, regardless of where in the page the text was selected.
The cause of the bug was that UpdateRootFrameMetrics was being called only if the app utilised the `AndroidDynamicToolbar`. This caused the `mViewportZoom` value inside `GeckoSession` to always be 0. When using the `clientToFrameMatrix` function to place the text selection toolbar on screen, the generated matrix was incorrect as the zoom value was 0, causing the resulting frame to be offset by the zoom value.
By ensuring that `UpdateRootFrameMetrics` is called inside `AsyncCompositionManager`even when there is no `AndroidDynamicToolbarAnimator` this zoom value is correctly set and the resulting frame for the text selection toolbar is correctly placed.
Differential Revision: https://phabricator.services.mozilla.com/D15941
--HG--
extra : moz-landing-system : lando
Setup RDM tooltip to not consume clicks and allow users to interact with the RDM on first try. The behavior of consuming clicks led at least one user to believe RDM could not be closed and filed a bug. Likely others encountered the same (small) road block when trying other actions.
Differential Revision: https://phabricator.services.mozilla.com/D15943
--HG--
extra : moz-landing-system : lando
Port to separate SpatialId from ClipId in Webrender API (WR PR #3251).
Patch was originally written and reviewed on bug 1503447.
Depends on D16005
Differential Revision: https://phabricator.services.mozilla.com/D16006
--HG--
extra : moz-landing-system : lando
The focus event listener in editor is system group, so synthesizeKey and/or synthesizeMouse doesn't work on focus event since editor doesn't initialize selection yet. So use setTimeout to work synthesizeKey and etc well.
Differential Revision: https://phabricator.services.mozilla.com/D15926
--HG--
extra : rebase_source : bbedd32278c94f009c7ab0e9d685979887b2f031
Editor initializes selection and input context (via IMEStateManager) on focus
event. But if content script calls stopImmediatePropagation on focus event,
editor cannot initialize these since editor cannot receive focus event.
It means that Android widget doesn't open virtual keyboard since
GeckoEditableSupport::SetInputContext isn't called. Also, Firefox desktop
doesn't show caret in this situation since selection isn't initialized in
editor.
So the event listener of focus and blur event should use system group.
Differential Revision: https://phabricator.services.mozilla.com/D15921
--HG--
extra : rebase_source : 71ab7e4aa043bac43e307dd6dfe4e84073d5154f
This patch changes all size limits in CacheObserver to kilobytes. The same unit is used at most places when checking these limits. This avoids uint32_t overflow when converting to bytes and back.
nsTimerEvent goes through a multi-step initialization for reasons that
are lost to time. We are also seeing peculiar crashes in
`nsTimerEvent::SetTimer()` that are only explainable by `SetTimer`
finding a non-null pointer where there should have been a null pointer.
The compiler ought to have been able to optimize those bits away, but no
matter: we can do the job ourselves and make the code clearer.
Since we only call `SetTimer` once, we should just move its work into
nsTimerEvent's constructor.
Doing this code movement separately will ideally make the next part of
this work easier to review. The idea is that we want to extract all the
necessary information from `timer` before we pass ownership of it into
the newly-allocated nsTimerEvent.
Unlike many of our uses of `new`, nsTimerEvent has its own definition of
`operator new`, to ensure instances are allocated through
TimerEventAllocator. And allocating with TimerEventAllocator can fail.
Later changes, however, want to assume that constructing an nsTimerEvent
can't fail, which is difficult to guarantee with the current structure.
To make that guarantee, we need to make explicit what calling `new`
does: there's an "allocate memory" step and a "construct the object"
step. The first part can fail, and that's what we care about here.
Once we have a chunk of memory, we can construct the object as normal,
secure in the knowledge that calling (placement) `new` is now guaranteed
to succeed.
