This patch takes the approach to count up to 100 wakeups and reports then time it took for that period. Regression in wakeups could
show up as decreased mean or median time.
Differential Revision: https://phabricator.services.mozilla.com/D32543
--HG--
extra : moz-landing-system : lando
This patch also contains some other cleanups to avoid the need for
special-casing getting symbol IDs at call-sites.
Differential Revision: https://phabricator.services.mozilla.com/D33543
--HG--
extra : moz-landing-system : lando
When comparing compatibility versions we first compare the version part. If that
shows us to be a downgrade then we stop checking at that point. But we must also
stop checking if it shows us to be an upgrade since we don't need to check the
build IDs at that point. This also applies to the check for the app build ID.
This means that a newer version with an older build id will appear to be a
downgrade.
This is problematic for safe mode because when safe mode runs it sets the
compatibility version to "Safe Mode" (bug 1556831) to ensure that caches are
invalidated on next startup. On the next run the Firefox version is considered
as newer than "Safe Mode" so we would move on to comparing the build IDs. But
the Firefox build ID gets version compared to "" (since there isn't a build ID
part in "Safe Mode"). Since build ID's are larger than 32-bit numbers we trigger
bug 1556829 and the actual comparison depends on the value of the build ID
truncated to 32-bits. This seems to often be negative and so lower than the
apparent previous build ID causing us to think this is a downgrade.
Cue nfroydnj saying I told you so because if I'd written this as a more
traditional compare function as he suggested I probably would have caught this.
Differential Revision: https://phabricator.services.mozilla.com/D33702
--HG--
extra : rebase_source : bb506c4ba4d75a68976bb114015d53cd41b4d4c3
When we're lowering extra types (e.g. array element types) and we find
that we haven't already lowered the type, we say that the new type is
going to live at the end of the `types` array. But we don't append a
new type (i.e. filling in the entry) until after we call `lower_type`,
which means that some other call to `lower_extra_type` might find
that *its* new type will live at the same position we "allocated" higher
up on the stack.
We don't appear to run into this issue, as the only nested array types
are things like `Array<Array<uint8>>`, and `uint8` is guaranteed to
already have been lowered. But if people start doing more complicated
things, we're bound to run into this sooner or later.
Differential Revision: https://phabricator.services.mozilla.com/D33299
--HG--
extra : moz-landing-system : lando
This is similar to this Chromium change:
https://codereview.chromium.org/1155353002
The editing spec doesn't mention editing non-HTML documents, and historically
this is only a feature that WebKit has supported. Supporting this feature
increases the attack surface of the browser without a clear benefit, so it
seems like a good idea to converge on this behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D32913
--HG--
rename : testing/web-platform/tests/html/editing/editing-0/making-entire-documents-editable-the-designmode-idl-attribute/user-interaction-editing-designMode.html => testing/web-platform/tests/html/editing/editing-0/making-entire-documents-editable-the-designmode-idl-attribute/user-interaction-editing-designMode-xml.xml
extra : moz-landing-system : lando
* CreateFileW will return INVALID_HANDLE_VALUE (-1) on failure, not NULL (0).
* MapViewOfFile will map the entire section if the size is 0. No explicit size
is required.
* If SEC_IMAGE is specified, the mapped image size may be different from the
file size on the storage.
Differential Revision: https://phabricator.services.mozilla.com/D32563
--HG--
extra : moz-landing-system : lando
PresShell::EventHandler::HandleEventWithCurrentEventInfo is the only possible
place will do such handling; other places pass either a nullptr or a
non-MouseDown/Up event.
Differential Revision: https://phabricator.services.mozilla.com/D32431
--HG--
extra : moz-landing-system : lando
Since the purpose of mCurrentEventLoopDepth is to be ordered in comparison with
mNestedEventLoopDepth, it's a bit deceptive to give it a value that would appear
to be less than any reasonable depth but is, because the variables in question
are unsigned, actually greater than any reasonable depth. Using
mozilla::MaxValue<uint32_t>::value is clearer.
Differential Revision: https://phabricator.services.mozilla.com/D32198
--HG--
extra : moz-landing-system : lando
PrioritizedEventQueue's template is always EventQueue, so the template
argument is rather useless.
Trying to keep the patch minimal, so CreateMainThread for example is still
a bit weird.
Differential Revision: https://phabricator.services.mozilla.com/D31871
--HG--
extra : moz-landing-system : lando
This removes the XRE_TakeMinidumpForChild() which does not need to be
exposed anymore in the XUL API as well as
IToplevelProtocol::TakeMinidump() which was simply unused.
Differential Revision: https://phabricator.services.mozilla.com/D31062
--HG--
extra : moz-landing-system : lando
Matt Woodrow
Olli Pettay
Daniel Varga
Csoregi Natalia
Nika Layzell
Boris Zbarsky
shindli
Mike Hommey
Dave Townsend
Brian Hackett
Mirko Brodesser
Nicklas Boman
Jonathan Kingston
Nathan Froyd
Honza Bambas
Gijs Kruitbosch
Ehsan Akhgari
Masatoshi Kimura
Edgar Chen
Jonathan Kew
Aaron Klotz
Jean-Yves Avenard
Sylvestre Ledru
Gurzau Raul
Randell Jesup
Gabriele Svelto
arthur.iakab
Kartikaya Gupta
Jim Blandy
Cosmin Sabou
Dzmitry Malyshau
Sean Feng
Bastien Orivel
ffxbld
Brian Birtles
Emilio Cobos Álvarez