Summary:
We'll be adding the new periodic file updates task to run in parallel. This patch
moves the existing one to make it clear it's running on buildbot, so we don't get confused
later on.
Reviewers: Callek
Reviewed By: Callek
Bug #: 1436369
Differential Revision: https://phabricator.services.mozilla.com/D681
--HG--
rename : taskcluster/ci/repo-update/kind.yml => taskcluster/ci/repo-update-bb/kind.yml
extra : rebase_source : c1386a05c378589efdd508199d97cb8121308686
It seems `doCommand` runs through a different codepath than just clicking the checkbox,
and as a result the outcome of the command handler is different that way.
This aligns the automated test closer to what happens when you 'manually'
click the checkbox, and fixes the bug in the command handler.
MozReview-Commit-ID: ACxRUxB35px
--HG--
extra : rebase_source : 7bc6d048d4ff6061aae6289e26f2b298820ed5ec
<!-- Please describe your changes on the following line: -->
Add WebGL function glGetTexParameter
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix part of #10209
<!-- Either: -->
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: f5037cf6219cafbc86bfaf6483b81b4ffb3496fa
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 0cb9a7a270dca8cbaa1a989633b77ba854042c49
These were mostly exported because APZCTreeManager included them and now
they don't need to be exported any more.
MozReview-Commit-ID: 8W3vKOvzYW3
--HG--
extra : rebase_source : 8da95a203692ab3a88d37e66071b914682b44f14
This also includes unified build fixes that were needed as a result of
the shuffling around.
MozReview-Commit-ID: 1AGG3DHnN1m
--HG--
extra : rebase_source : 7399cea6dff2bd91ab305dee22d93b32382cc0be
Callers should be using one of the more specific subinterfaces like
IAPZCTreeManager (for controller-API methods) or APZSampler (for
sampler-API methods). There's also a bunch of android-specific
dynamic toolbar code that uses this function - I don't want to
deal with that right now, so instead of removing it entirely we can just
make it Android-only.
MozReview-Commit-ID: I8DYWLYoFgP
--HG--
extra : rebase_source : 75e05825194f9c6843506bb5d82e1a0c6e2b08bb
Although CrossProcessCompositorBridgeParent still needs to create a
dummy APZCTreeManager of its own in place, we can at least stop it from
grabbing the "real" APZCTreeManager from CompositorBridgeParent, which
allows access to methods that might not be properly guarded with respect
to thread safety.
MozReview-Commit-ID: Btvez3OkFPs
--HG--
extra : rebase_source : a4bec1769ff2fb899bb2e65f99f8e715f9a94c44
Note that this value, 300, is still far above the 95% threshold that telemetry is reporting (59 milliseconds) so this won't be noticeable to most users. The > 1% of users who are having this issue will benefit greatly from this change.
MozReview-Commit-ID: Bd51gjc5z83
--HG--
extra : rebase_source : 4a9e96eb555e8021012a3a06cb76e03413a8da20
This was inadvertently removed when the preference attribute was removed to clean up a race condition.
MozReview-Commit-ID: 8yNPMwkGS3u
--HG--
extra : rebase_source : f6381588a47bc0bbd9c2b087ded55a85d131ec03
In Bug 1332680 we got a list of classes and methods we could mark 'final',
as suggested by an LTO build of gcc. One of the items on that list was
nsGlobalWindowInner and nsGlobalWindowOuter, with quite a lot of virtual
calls:
> dom/base/nsGlobalWindowInner.h:206:7: warning: Declaring type 'struct nsGlobalWindowInner' final would enable devirtualization of 483 calls
> dom/base/nsGlobalWindowOuter.h:164:7: warning: Declaring type 'struct nsGlobalWindowOuter' final would enable devirtualization of 143 calls
After trying it out, we saw a modest improvement to a single Talos tes
(displaylist mutate got 4-8.5% better). That's not the interesting
thing though.
For Linux and OSX (and some flavors of Android) build times were reduced
by half across the board. They're a bit variable of course, but 30-70%
improvements are shown by Talos. Windows and other flavors of Android
show 10-15% improvements.
MozReview-Commit-ID: GlEGBt2JOTt
Currently, HTMLEditor doesn't initialize caret position when it gets focus by
itself in most cases. Only when it's in designMode, it may move caret to the
first visible (not checking CSS actually).
In most cases, caret position is adjusted when EditorBase::InitializeSelection()
calls Selection::SetAncestorLimiter(). If selected range is outside of
new limiter, it moves caret to start of the new limiter. However, this is
really different behavior from the other browsers. The other browsers try
to move caret to the first editable text node or before the first editable
content such as <img>, <input>, etc.
This difference causes a serious incompatible issue with Draft.js. It doesn't
initialize caret position when it gets focus but it assumes that caret is
always set to before <br> element if there is no other content.
So, let's try to behave as what other browsers do as far as possible.
This patch makes editor behave as:
* if selection is already in the editing host except start of the editing host,
does nothing.
* if there is non-editable element before any editable node, move caret to
start of the editing host.
* if there is editable text node or element node which cannot have a text node,
move its start or before it.
* if there is no editable nodes which can contain text nodes, move caret to
start of the editing host.
Note that before applying this patch, in designMode, BeginningOfDocument() used
document element instead of <body> element. Therefore, it may set odd position
if <head> element has some text nodes with <script> or <style>. However,
this doesn't make sense and for making more consistent behavior between
designMode and contenteditable, this patch makes it use editing host (it's
<body> element if it's in designMode).
MozReview-Commit-ID: 5neYoTMq6Cc
--HG--
extra : rebase_source : c4d06b6864a221d7cd2833a007d73f7d67821e95
