This changeset adds a package.json, .npmignore and a readme file. They are used by the
'npm' command to publish the hybrid content telemetry library to the NPM directory.
MozReview-Commit-ID: KwGEhOmbfbW
--HG--
extra : rebase_source : 5c458289abed5d95c692c3020147574286576f86
If a key combination causes text input, we need to dispatch keypress
events without alt/ctrl/meta modifiers since TextEditor won't handle
keyepress events whose altKey, ctrlKey or metaKey is true as inputting
text.
Currently, TextEventDispatcher sets mCharCode of eKeyPress event from
mKeyValue. Then, when altKey, ctrlKey or metaKey is true, it'll call
WillDispatchKeyboardEvent() and then, TextInputHandler needs to reset
the charCode value from native event information.
However, the problem is, TextInputHandler::InsertText() is called
with control character when control key is pressed and InsertText()
clears the modifier information before sending eKeyPress event to
TextEvenDispatcher so that TextEventDispatcher won't call
WillDispatchKeyboardEvent() even though control key is actually
pressed. Therefore, TextInputHandler cannot adjust charCode value
and modifier flags in some cases such as control + option + 'a'.
This patch makes InsertText() stop clearing the modifiers and
makes WillDispatchKeyboardEvent() do it instead. This procedure
is expected by TextEventDispatcher.
MozReview-Commit-ID: Ig6qgRBeQDh
--HG--
extra : rebase_source : 446e8af0e921946f3409d26ede70446248317673
Previously we used the tweakExpectedRestyleCount function (replaced by the
waitForAnimationReadyToRestyle function in the previous patch) only in cases
where we were actually expecting restyles to happen. For cases where we don't
expect restyles, i.e. cases where we assert the restyle count is zero, we
didn't use this method meaning we didn't bother checking if there was a restyle
expected for the current frame or not.
Since we normally wait for 5 frames anyway before checking that there have been
no restyles, failing to count the number of frames and waiting only 4 frames is
not a problem. However, if a new test were added that just copied this code and
only waited one frame, it might fail to test what it intended. So, to avoid
possible future bugs and in order to be more consistent with tests that do
expect restyles, this patch replaces a number of uses animation.ready with
waitForAnimationReadyToRestyle.
MozReview-Commit-ID: 7qBmobTKolh
--HG--
extra : rebase_source : baa272102fed7a66cc4fc89f6d63ba0333087a2d
And replace tweakExpectedRestyleCount with the function.
MozReview-Commit-ID: 96jC9looyZq
--HG--
extra : rebase_source : 7dae8b258b874a9b366767a6e49de83bf2caccc9
The crash reporter symbol files are the easiest cross-platform way to
find static initializers. While some types of static initializers (e.g.
__attribute__(constructor) functions) don't appear there in a notable
way, the static initializers we do care the most about for tracking do
(static initializers from C++ globals). As a matter of fact, there is
only a difference of 2 compared to the currently reported count of 125
on a linux64 build, so this is a good enough approximation. And allows
us to easily track the count on Android, OSX and Windows builds, which
we currently don't do.
The tricky part is that the symbol files are in
dist/crashreporter-symbols/$lib/$fileid/$lib.sym, and $fileid is hard to
figure out. There is a `fileid` tool in testing/tools, but it is a
target binary, meaning it's not available on cross builds (OSX,
Android).
So the simplest is just to gather the data while creating the symbol
files, which unfortunately requires to go through some hoops to make it
happen for just the files we care about.
--HG--
extra : rebase_source : 458fed1ffd6f9294eefef61f10ff7a284af0d986
This was changing the project from "main" -> ("main",) which was causing the DocUp
task to upload to urls like:
"('main',)/62.0/_sources/..."
MozReview-Commit-ID: 1bL9nqiAEFE
--HG--
extra : rebase_source : 8f4148dd003dfcfb4c0ba513e4fa7e2ca540dce3
Let's see if this manages to reopen the CLOSED TREE. It's either raciness on
load, or it's timing out, so I hope it's this, really.
MozReview-Commit-ID: KUbJvRcTlNF
There are some places where we have a thing which may not even be a node, and
we end up hardcoding the value of DOCUMENT_NODE there, because
"foo.nodeType == foo.DOCUMENT_NODE" will test true if foo is not a node: both
sides will be undefined.
This was simply an oversight in the implementation of Bug 1464128.
What's happening is that `set_config` in `moz.configure` is not
unconditional, and NIGHTLY_BUILD is set in local builds and in B and N
builds in automation, so there was no test of the other case, which
promptly fails. This re-uses a pattern successful in mobile/android
for setting defines.
MozReview-Commit-ID: 4zL4hVsqE3Q
--HG--
extra : rebase_source : f6033ed9be0afde7d1a5502bf69234247c95b8ba
