This is already true for the audio sources. It should be for all.
Crashtests showed that shutting down amidst the async init can lead to
double-stops. It is impossible to completely protect yourself from them without
waiting for all queued operations to resolve (results to become known) before
taking action. Doing that would require a refactor in MediaManager and cause
higher latency for device operations so it seems like the wrong way to go.
MozReview-Commit-ID: 5Cci6whzTL7
--HG--
extra : rebase_source : f4dccbc5a56e33ecc54d63ddefbae43d90ee95d4
extra : source : f5cc71d38e4a7c0e4db830242c1d454fcbdb9e48
extra : histedit_source : 3cd8615054ce9935047e4168c3a472152792886b
This so that SourceListener can keep its internal state in sync with the result
of the start operation.
MozReview-Commit-ID: Cgl5TFnpCeW
--HG--
extra : rebase_source : e2cec60544efcc27c9c8c077fbdb013a8f3b848c
extra : source : 6c38cc382d2114199842dddb14097be8b6d9a961
extra : histedit_source : 00ef8da067eb484b8c5926d008f00f1e9f006e6f
mozWritePoison secretly depended on the passed-in pointer being aligned
as though it were a pointer to uintptr_t, as it used bare stores to
C-casted pointers to accomplish poisoning. But this is an unnecessary
limitation: we can use memcpy and rely on the compiler to appropriately
inline the store to an unaligned store instruction if necessary.
The documentation for mozWritePoison says that only an even number of
sizeof(uintptr_t) bytes are overwritten; any trailing bytes are not
touched. This documentation doesn't correspond to how the function
actually works. The function as written will happily overwrite trailing
bytes and any bytes not contained in the object, if the passed-in size
isn't divisible by sizeof(uintptr_t). Let's fix that.
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
