For preparing to fix bug 1465702, we need to split public methods of editor
which are used by both outside and itself or friends.
SelectAll() is used by both outside and TextEditor. So, we need to create
SelectAllInternal() and make TextEditor use it instead.
MozReview-Commit-ID: JtIlrfBYBSD
--HG--
extra : rebase_source : 5c29a9c1bb99f457f66f320b873b2c7b0f93fcde
90dca0906337 accidentally broke `mach artifact toolchain --from-build`
because that code is attempting to load toolchain tasks in isolation.
The new "use_fetches" transform added to toolchain tasks requires
that "fetch" tasks are already processed and their references are
available to toolchain tasks.
This commit adds a mechanism to effectively disable the "use_fetches"
transform when called by `mach artifact toolchain`. It is a hack. I
suspect future planned work around artifacts/fetches will necessitate
additional changes to the `mach artifact toolchain` code. But this
can be deferred to a later day: this commit unbusts `mach artifact
toolchain` and isn't super hacky, so it seems more reasonable than
backing out fetch tasks completely.
Differential Revision: https://phabricator.services.mozilla.com/D1588
We used to do that before bug 1455767. Taking a step back, what we want
(and what this change implements) is to:
- allow to specify a linker to use explicitly
- check that using the corresponding linker flags makes us use that
linker
- if no linker is specified, and developer options are enabled, we want
to try to use gold if it's available, otherwise, we want to detect
what kind of linker the default linker is
--HG--
extra : rebase_source : 655089f29c6403f6c31a977dcf5c6fd1e9941121
The WebAssembly Specification, branch [1] (see also, more generally,
comments in [2]), contains a new test, limits.js, to check whether the
generally agreed embedding limits (numbers of functions, imports, etc) are
observed. This bug is to import the test and fix any resulting breakage
detected with it.
[1] https://github.com/WebAssembly/spec/tree/embedding_limits
[2] https://github.com/WebAssembly/spec/issues/607
* js/src/wasm/WasmBinaryConstants.h:
- Added MaxTableMaximumLength as a counterpart to MaxTableInitialLength.
- Split the constant group into two parts: spec-required, and those
pertaining only to our own implementation.
* js/src/wasm/WasmJS.cpp WasmTableObject::construct():
- Update GetLimits call with correct max size bound
* js/src/wasm/WasmValidate.cpp DecodeTableLimits():
- Implement missing check for a Table's maximum size.
* js/src/jit-test/tests/wasm/import-export.js:
js/src/jit-test/tests/wasm/spec/jsapi.js:
- Update Table maximum size tests. All tests trying to make a Table
with more than 10,000,000 entries now throw instead of succeeding.
* js/src/jit-test/tests/wasm/spec/harness/wasm-module-builder.js:
- Import minimal updates and bug fixes from [1], needed to make the
new tests work.
* js/src/jit-test/tests/wasm/spec/limits.js
- New file. Derived from [1], with comments added to each test to show
SM's compliance situation, and with two tests disabled.
--HG--
extra : rebase_source : a1f1ec730ecae22f2aa0f510c15ebc934489a1b3
Currently, TabChild discards eKeyDown and eKeyPress events which are marked as
"repeated" and were dispatched after the latest eKeyDown event comes into the
process. However, keyboard layout utils may generate native key events
as "repeated" even if each native key is important to input proper text.
So, TabChild shouldn't decide if coming keyboard event is skippable only with
mIsRepeat. For solving this issue, this patch adds
mMaybeSkippableInRemoteProcess to WidgetKeyboardEvent and makes
TabChild::SkipRepeatedKeyEvent() check
WidgetKeyboardEvent::CanSkipInRemoteProcess() instead.
On Windows, there are two ways to generate keyboard input messages. One is
using SendMessage() or PostMessage(). The other is SendInput() API. In both
ways, utils can make their input as repeated key messages.
The former case must be safe for this issue since such utils need to set 31st
bit of lParam to 1 explicitly.
On the other hand, in the latter case, the utils probably need to append
KEYEVENTF_KEYUP into KEYBDINPUT::dwFlags. Otherwise, only first call is
treated as non-repeated event.
So, when given message does not came from physical key operation, NativeKey
should set WidgetKeyboardEvent::mMaybeSkippableInRemoteProcess to false
even if WidgetKeyboardEvent::mIsRepeat is true.
MozReview-Commit-ID: 3rinrOjx8Tf
--HG--
extra : rebase_source : 26b6d869260176fc7ef535323b83001bb4b725c2
The trigger is missing a WHERE clause, and as such it ends up doing a lot more work than necessary.
The nsAutoCompleteController changes cover a bug where VK_RIGHT autofills when it's not necessary,
and by doing that it will move the caret to an unexpected position (far right) even if it didn't
actually complete some preselected text.
MozReview-Commit-ID: 1mVbxCdqVSr
--HG--
extra : rebase_source : 9a7e13cc62dfe0ae95210e7a75068d07a0b7c275
After fixing the document.domain exceptions to conform to the html
spec, NS_ERROR_DOM_BAD_DOCUMENT_DOMAIN is no longer used, and can be
removed.
MozReview-Commit-ID: 9CwrUSGy2K3
--HG--
extra : rebase_source : 6c624e407fd714f8c61e1e43d44089c0c1e64558
Change exception type to comply with HTML spec, which uses security
error instead of bad document domain.
MozReview-Commit-ID: Iefkeskn9bM
--HG--
extra : rebase_source : 282507d687c8fe19a326df95632694bcc6c5dd29
Merged Rsdparser changes from github to mozilla central.
This includes: Syntax fixes for older rust versions
The TransportCC parameter for rtcp-fb
Serialization marcos and code
MozReview-Commit-ID: JqYttvTx2QS
--HG--
extra : rebase_source : 4f0c9e374fcdbd01d729cda2ddbfe5c67bf6cbc9
When the study preference (shield.savant.enabled) is set to true, this will record:
* When an addon begins an install
* When an addon finishes an install
* When an addon is enabled
* When an addon is disabled
* When an addon begins an uninstall
* When an addon finishes an uninstall
MozReview-Commit-ID: J8LoBZVS5iL
--HG--
extra : rebase_source : da9715876a9f19c8655a74bd0558cb074788ada5
1. Updated hgrepo to work with mozilla-beta, mozilla-esr60 and project branches (just in case)
2. Presquashed commits, so we only submit one.
3. Replaced 'which' with 'command -v' to avoid future shellcheck issues.
Differential Revision: https://phabricator.services.mozilla.com/D1582
Transforms are containing blocks for fixed-pos items, so if a fixed-pos
item is inside a scrolled transform, then it should use that scrollframe
as the scroll target for hit-testing. This patch handles this case for
WebRender by stashing the appropriate ASR on the nsDisplayFixedPosition
item and using it instead of the presShell's root scrollframe in this
scenario.
The patch also adds a mochitest (which is basically a mochitested
version of the reftest in fixed-pos-scrolled-clip-3.html, with a
hit-test check to ensure that it's hitting the right scrollframe).
MozReview-Commit-ID: 7YQAeOiMMuP
--HG--
extra : rebase_source : 8d1c89d0c03c3e7d9383d0731f65a327a2c11a8d
Without this patch, the scrollId for display items inside a fixed-pos
item end as the ASR of the item. In the case of fixed-pos items that are
inside iframes, the ASR is the outer document's root scrollframe. This
means that e.g. wheel-scrolling while over a fixed-pos item inside an
iframe ends up scrolling the outer document's root scrollframe instead
of the iframe's root scrollframe.
In the non-WR codepath, there some APZ machinery that walks up in the
HitTestingTreeNode tree from the hit result, looking to see if that node
has a fixed-pos ancestor, and if so, uses the fixed-pos item's target
APZ as the real hit result. This machinery doesn't exist in WR, because
we don't use the HitTestingTreeNode tree for hit-testing in APZ.
Instead, we need to make sure that the item tag for those display items
already has the appropriate scrollid set.
This patch accomplishes this by introducing a new RAII class that is
pushed into the wr::DisplayListBuilder while we are building display
items inside a nsDisplayFixedPosition, and allows the desired scroll id to
be set on the hit-testing display items.
This behaviour is exercised by test_group_wheelevents, which can now be
enabled with this fix.
MozReview-Commit-ID: L2erPVzJeql
--HG--
extra : rebase_source : 1db630513cb1dc16d4e38649812e81f62c8da99c