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
These values were computed by measuring compilations of a set of
programs on ARM64 reference hardware using --no-threads and then
applying sane multipliers to estimate Ion values where we don't yet
have them (because we don't have Ion on ARM64).
See the bug for a table of raw data. See comments in the code for
more information about what the values mean.
--HG--
extra : rebase_source : 918e9fbc9a9f2a0119967fdc96162c9e2f309a84
extra : amend_source : 0d1a703cddb4225e8a32b1bebfa0ad5efe14a0a9
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.
We can avoid making an extra copy when unescaping `mScrollToRef` by using
`NS_UnescapeURL` instead of `nsUnescape`. Additionally we can avoid calling
`GoToAnchor` a second time if nothing was unescaped.
--HG--
extra : rebase_source : 9a792e5bbd54b58a8bc0db4b9aa47b4048f985a0
For navigation: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
For images: image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5
for style: text/css,*/*;q=0.1
Anything else: */*