It's always used along with nsChangeHint_RepaintFrame, which does most of the
work.
It's only useful to skip calling SyncFrameViewProperties(). That call is really
cheap if nothing actually changed, furthermore since only a handful of frames
actually have views.
So it doesn't seem like it serves any useful purpose.
Differential Revision: https://phabricator.services.mozilla.com/D48003
--HG--
extra : moz-landing-system : lando
Since when the updater isn't enabled the buttons aren't included, so the
`getElementById()` call fails and breaks the main preferences page.
Differential Revision: https://phabricator.services.mozilla.com/D48452
--HG--
extra : moz-landing-system : lando
Otherwise we may keep the scroll anchor around and we may try to anchor to it
later even though we should've really suppressed it completely.
Maybe we should just call InvalidateAnchor() unconditionally from that code
path, even if there are no suppressions pending...
Differential Revision: https://phabricator.services.mozilla.com/D48456
--HG--
extra : moz-landing-system : lando
This version includes a fix necessary to distributing builds to multiple
servers as well as several important fixes to the client that will help
people attempting to distribute compiles. Once a bit more testing has been
seen we will update the required version used locally to 0.2.12.
Differential Revision: https://phabricator.services.mozilla.com/D48441
--HG--
extra : moz-landing-system : lando
This makes things better especially when the bounds of the combined blob
is changing but the bound of the separate ones are not.
The current implementation is a bit ugly, but it's simple and
can be cleaned up in the cleanups I have in mind for the future.
Differential Revision: https://phabricator.services.mozilla.com/D47983
--HG--
extra : moz-landing-system : lando
Chrome and old Edge at least seem to have this behavior, and this way the testcase on the bug doesn't trigger click anymore since
we enter dnd mode and get dragleave etc. events.
Manually tested on linux and Windows, and annyg tested on Mac
Update test_dragstart.html's draggable=true test to follow the pattern used by other tests
Differential Revision: https://phabricator.services.mozilla.com/D48208
--HG--
extra : moz-landing-system : lando
Previously we assumed that we could trust the `OnLocationChange`,
`OnStateChange`, and `OnSecurityChange` IPC messages from the BrowserChild to
BrowserParent to always contain their optional data if the message was
top-level. However, if a content process becomes compromised, this could be
used to DOS the parent process by maliciously sending these messages to the
parent process with invalid data.
Now we explicitly check that the data is valid before derefing.
Differential Revision: https://phabricator.services.mozilla.com/D48423
--HG--
extra : moz-landing-system : lando
Now all traits of the tab target are stored inside reducers/threads via the navigate action, and getters of two of them (wasmBinarySource, canRewind) are explicitly exported.
Differential Revision: https://phabricator.services.mozilla.com/D48287
--HG--
extra : moz-landing-system : lando
In addition to normal bindings, which always use a proper identifier name, the
|this| binding can also be optimised out for arrow functions. The |this|
binding is stored in a binding named ".this", which, because it doesn't match
the IdentifierName syntax, triggered an assertion when generating its printable
representation. Workaround this assertion by special-casing ".this" when
reporting optimised out bindings.
Differential Revision: https://phabricator.services.mozilla.com/D47238
--HG--
extra : moz-landing-system : lando
In previous code, the selectedLocation can be a non-empty object containing a line number of 0, which will cause the sourceMap to complain and halt the jumping procedure. I added a check to make sure that the sourceMap branch is only executed when the selectedLocation makes sense.
Differential Revision: https://phabricator.services.mozilla.com/D48290
--HG--
extra : moz-landing-system : lando
Now all traits of the tab target are stored inside reducers/threads via the navigate action, and getters of two of them (wasmBinarySource, canRewind) are explicitly exported.
Differential Revision: https://phabricator.services.mozilla.com/D48287
--HG--
extra : moz-landing-system : lando
Automatic update from web-platform-tests
Remove unused --channel=experimental for resources/ tests
The argument is documented as "Chrome browser channel" and isn't used
here because Chrome isn't involved.
--
wpt-commits: e2381a6676f1ae4a491cfbac5805d25d491798a2
wpt-pr: 19342
Automatic update from web-platform-tests
Test origin-offset for `viewer` space
Bug: 1009129
Change-Id: Iea0ee4259c894db49a76f8f4e1ca9b53f95f69ad
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1829296
Commit-Queue: Piotr Bialecki <bialpio@chromium.org>
Reviewed-by: Klaus Weidner <klausw@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/master@{#701468}
--
wpt-commits: 187e0e0d82dd6c2440ae6673b5ed2e130dc61a70
wpt-pr: 19409
Automatic update from web-platform-tests
Revert "Update emulated position on each XRFrame"
This reverts commit 8be89ae08126913ff4447927ac5a087b8d6babcf.
Reason for revert: Build failure:
https://ci.chromium.org/p/chromium/builders/ci/Win%20x64%20Builder/79827
[4142/15096] CXX obj/device/vr/vr/openxr_controller.obj
FAILED: obj/device/vr/vr/openxr_controller.obj
C:\b\s\w\ir\cache\goma\client\gomacc.exe ..\..\third_party\llvm-build\Release+Asserts\bin\clang-cl.e...(too long)
../../device/vr/openxr/openxr_controller.cc(204,19): error: no member named 'emulated_position' in 'device::mojom::XRInputSourceDescription'
description_->emulated_position = false;
~~~~~~~~~~~~ ^
1 error generated.
Original change's description:
> Update emulated position on each XRFrame
>
> For both the head poses and input poses, send this value through mojo
> from the device process to the renderer process on every frame.
>
> Bug: 969131
> Change-Id: Ie895deb75bddb6dd883d09828cfcb30f335d3793
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1825478
> Auto-Submit: Jacob DeWitt <jacde@chromium.org>
> Commit-Queue: Will Harris <wfh@chromium.org>
> Reviewed-by: Will Harris <wfh@chromium.org>
> Reviewed-by: Klaus Weidner <klausw@chromium.org>
> Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#701389}
TBR=dcheng@chromium.org,wfh@chromium.org,klausw@chromium.org,jacde@chromium.org,alcooper@chromium.org
Change-Id: I91ec66842b8f0a14bcb85145843fb4d617847066
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 969131
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1833005
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#701401}
--
wpt-commits: 1eb937d8403daa35e94bec451643228f85831222
wpt-pr: 19428
