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
Because testing/marionette/CONTRIBUTING.md is hard to find and not indexed
anywhere, this patch moves all its content to the online documentation
at https://firefox-source-docs.mozilla.org/testing/marionette/marionette/.
The file has been split up in four documents:
* Contributing.md, which covers introduction to new contributors
and a brief summary of the Marionette architecture.
* Building.md, covering build instructions.
* Patches.md, explaining how to write and get patches reviewed.
* Testing.md, which explains how to test a patch.
MozReview-Commit-ID: HuEAls8Kpfg
Negative input times would carry a negative sign all the way
through to where we do pointer math. That's bad, and embaressing.
As far as I know, there was no way to have the resulting value be
outside [-32, 28]. We coerce it down to [0, 28] to always stay in
bounds.
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
Now the test works fine with the new microtask handling.
MozReview-Commit-ID: EhFcN2XAClw
--HG--
extra : rebase_source : f1066bf09df07c1bcbfe5dc5dcc59596530424d0
Bump nestegg to commit 89ed0daf2edccb25f744e5faff88b8b4684adceb. This brings
across tolerance of blocks with negative timecodes. Instead of rejecting these
the timecodes are now set to 0.
Also brings across a change to appease clang in ne_read_block_additions by
adding an explicit assignment to data_size.
MozReview-Commit-ID: 7J8YPUUwSBp
--HG--
extra : rebase_source : f55bd987465baf21f383095b60e9148349936fef
mNeedStyleFlush is also set by animation restyle request. So it's possible
that the flag is set again in PostRestyleForThrottledAnimations() or in
sequential tasks for updating animations after the flag is cleared at the top
DoFlushPendingNotifications().
MozReview-Commit-ID: KPSS6cJb4HX
--HG--
extra : rebase_source : 31d839f12b654d52b352cd50e19bc1953c46b7c2
I accidentally broke the ability to retrieve a big string from the
clipboard, and there was no test that failed. So this provides a new
test that does the following:
1. Store a big string in a nsTransferable.
2. Copy it to the clipboard.
3. Create a new nsTransferable, initialize with small data.
4. Populate the nsTransferable with (big) data from the clipboard.
5. Populate the nsTransferable with small data.
After each step, the test checks whether the transferable holds the
expected data and length, and (on non-Windows) checks that the big
data is backed by a file, and small data is not.
MozReview-Commit-ID: 9yuXZxVqD6R
--HG--
extra : rebase_source : 6cec638c59e8ce5a18adbb642779c1dcd457cc5b
DataStruct cannot safely be copied if its mCacheFD member is set.
Currently there is no code for this case, but to avoid problems later,
mark the copy and assignment constructors private and delete them.
A move-constructor was added to compensate for the deleted copy
constructor. nsTransferable::AddDataFlavor uses this new constructor
instead of the previous implicit default copy constructor.
MozReview-Commit-ID: 3N5xjFXOUKB
--HG--
extra : rebase_source : dc609f20c7048b3630fa99fe2deef3f5be155334
- Count open file descriptors instead of testing the existence of a file
(because the clipboard is now only reachable through file descriptors,
and not through a file path).
- Use a fixed string instead of a random string. The previous way of
generating a string was non-deterministic, and there was a very small
chance that the generated string was not large enough to trigger the
cache-to-disk-mode.
- Use "text/unicode" instead of "text/plain", because JavaScript strings
use two bytes, not one bytes each.
- The cache file is already created when the Transferable is created, so
check the cache file after assigning data to the nsITransferable, but
before copying it to the clipboard.
MozReview-Commit-ID: KOkYOm280Oh
--HG--
extra : rebase_source : 3515ff55a316720b87f2473a1450e5d8304728e8
When capturing the JavaScript stack as a chain of SavedFrames, the
hasCachedSavedFrame flag on a frame indicates that the frame has an entry in
the LiveSavedFrameCache, which may hand us the SavedFrame for a previously
captured remainder of the stack, letting us stop the stack walk early.
The LiveSavedFrameCache uses AbstractFramePtr and jit::CommonFrameLayout* values
as keys. A RematerializedFrame uses an AbstractFramePtr as its key, but the
BaselineFrame we build from it has a jit::CommonFrameLayout* as its key; the two
keys are unequal. It's valuable to be able to assert that, if a frame has its
hasCachedSavedFrame flag set, then it must have an entry in the cache; to allow
that, converting a RematerializedFrame to a BaselineFrame must clear the flag,
since the BaselineFrame's key is not present.
We could instead fix up the cache entry's key, and carry over the flag, but it's
simpler to just let the cache get repopulated as needed.
MozReview-Commit-ID: 612daDJ1R4w
--HG--
extra : rebase_source : c528eafff0b1d7eeaa5f7c688a6c82631f5282a6
