The overall progress is factored in iteration start, so even if
TimingParams.mIterations is less than UINT64_MAX, it will exceed UINT64_MAX.
MozReview-Commit-ID: CEOYAGsCoIE
--HG--
extra : rebase_source : 54ed450ebd0218ee2cac9f27125601c6575ee1a5
Because our ComputedTiming.mCurrentIteration is uint64_t.
MozReview-Commit-ID: FjbhEvTUMr4
--HG--
extra : rebase_source : d8ba72c914aac6661f0a5a21885505f94844ce38
In Bug 1380421 we reverted some behavior that required Web Authentication's
RP ID to be domain string to permit it to be an origin, too, for interop
testing. That is no longer needed, so this patch resumes enforcement that
RP ID be a domain string.
It also adds a needed test that the RP ID hash is calculated correctly.
MozReview-Commit-ID: 8dDjzo5kQKP
--HG--
extra : rebase_source : 65cd7b9f3a6ecfc58805daf102f33966c9b19b98
Per IRC dicussion, there is no technical or policy restriction on dependencies
within a task kind. Update the documentation to remove the out-of-date mention
of this limitation. In particular, toolchain build tasks tend to depend on
each other.
MozReview-Commit-ID: K6p0mxyjcvY
--HG--
extra : rebase_source : 9439503e8f0a278b1bb41d8a71a2d31d5fc9c0e8
This is just the most conservative thing we can do to get the
Flash doorhanger to not look out of place next to other
doorhangers. This does not change the doorhanger's strings or
anything substantive. Still looking into what that would entail,
but I thought I would drop this in as a baseline.
Minor notes: added default="true" to get the OS-specific button
reordering of normal doorhangers, and removed the close button
since the doorhanger will close by just clicking out of it.
MozReview-Commit-ID: 9jhHLfzSeXZ
--HG--
extra : rebase_source : b206531f0b916502bc4917ae93f1e95ec9909c8e
The optimization avoided a 10ms delay in generating synthesized mouse events
after a touch tap, if the tapped element wasn't styled differently when in
the |:active| state.
This dates back to the B2G days when the delay was in the critical path of
app startup times. It's less important today, and determining whether the
element is styled differently is an expensive operation in the style engine,
so we are removing it.
MozReview-Commit-ID: FYO1GlCR3gS
--HG--
extra : rebase_source : 1b7ce6eec77d0260b153bfcd93e81bccb3558107
Since LinearHistogram and its descendants inherit ranges_ from
Histogram, and we wanted to replace the copying into a std::vec
for Histogram, the simplest approach seemed to just be to
precompute ranges for all histograms, exponential or otherwise.
This should have the added benefit of reducing the memory
footprint for those histograms, since they will benefit from the
deduplication work that the precomputing script already does.
MozReview-Commit-ID: JTV5Dej5ZIb
--HG--
extra : rebase_source : de942d54b3475be54c70d43d2fa8e772ee2e18c4
This is a fairly small optimization - since the indices for this
array never exceed the size of an int16_t, let's just use that
instead to save a little bit of space.
MozReview-Commit-ID: 8bRokjlvZ9p
--HG--
extra : rebase_source : b74bd0d6c36ecbb83db8ce6659f1484bfa3b885e
Since we already have the indices array, we can just point duplicate
ranges at the first occurrence's index.
MozReview-Commit-ID: 3f5os1xSp89
--HG--
extra : rebase_source : 68a859716aeafd3330b4b0b728f77c537a5020aa
Seeing an NSVO in CreateObjectsForEnvironmentChain indicates the shared
global namespace is about to be polluted, so fix those bugs and turn
this to a diagnostic.
MozReview-Commit-ID: 7OUef76geJL
--HG--
extra : rebase_source : 487ab155a11e41d01b7195ac974b46e3bd2199b6
When using the subscript loader with JSM global sharing, it was possible
that subscript would pollute the global of all JSMs in the sharing.
MozReview-Commit-ID: 1ah5JUAZwBA
--HG--
extra : rebase_source : 5fecf7dc61019431d67bcee4199e40a8278c8c64
This allows js::ExecuteInJSMEnvironment to take a target object argument
as used by the subscript loader. This adds WithEnvironments with a
corresponding lexical on top of the ordinary NonSyntacticVariablesObject
environment chain.
MozReview-Commit-ID: JhHEfV92Zpv
--HG--
extra : rebase_source : d1ef9564d30a25fd9e1cf1ca7e95bf40c780dcdf
Mozjemalloc uses its own doubly linked list, which, being inherited from
C code, doesn't do much type checking, and, in practice, is rather
similar to DoublyLinkedList, so use the latter instead.
--HG--
extra : rebase_source : 9eb7334b6dde05f9af0eaea4184e532c69d0264e
While the flexibility of the current trait is nice, it's actually not
used to its fullest anywhere, and is boilerplate-y. While it is useful
to be able to put the links anywhere, there's not much usefulness from
being able to split mNext and mPrev.
So instead of a trait that allows to get/set mNext and mPrev
independently, we just use a trait that tells how to get a reference to
a DoublyLinkedListElement from a list element itself.
--HG--
extra : rebase_source : 674277bac4fc979f2e483a77b5ef1495baccc7fe
The combined button widget issue only appeared on OSX.
MozReview-Commit-ID: 3T05WDUCPrQ
--HG--
extra : rebase_source : dc84ddf89ef94ffcde3ce4fb68fc57c38059aeff
