In bug 1356448, the RDM tests are causing trouble in Windows 32-bit platforms,
so let's disable them for all Windows runs.
The timing of these tests appears to be very different on Windows platforms,
even though the production functionality works correctly, so more investigation
is needed.
MozReview-Commit-ID: 3BBbladg5Pl
The old archive was uploaded with internal visibility. This was almost
certainly a mistake.
I downloaded the old archive and produced a new one and re-uploaded it to
tooltool with public visibility. I had to reproduce the archive because
tooltool won't let you promote an existing item to public.
It appears that environment state and possibly differences in the
tar command result in diverging tar archives. For example:
==> clang.orig <==
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/bin/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/include/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/lib/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/libexec/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/clang/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/man/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/scan-build/
drwxr-xr-x ehsan/wheel 0 2017-02-01 20:34 clang/share/scan-view/
==> clang.new <==
drwxr-xr-x gps/gps 0 2017-02-01 20:34 clang/
drwxr-xr-x gps/gps 0 2017-02-01 20:34 clang/bin/
-rwxr-xr-x gps/gps 18099 2017-02-01 20:15 clang/bin/git-clang-format
-rwxr-xr-x gps/gps 6731340 2017-02-01 20:33 clang/bin/llvm-mc
-rwxr-xr-x gps/gps 2241688 2017-02-01 20:34 clang/bin/obj2yaml
-rwxr-xr-x gps/gps 17105264 2017-02-01 20:33 clang/bin/llvm-c-test
-rwxr-xr-x gps/gps 13153616 2017-02-01 20:33 clang/bin/bugpoint
-rwxr-xr-x gps/gps 49666672 2017-02-01 20:33 clang/bin/clang-3.9
-rwxr-xr-x gps/gps 52901 2017-02-01 20:15 clang/bin/scan-build
-rwxr-xr-x gps/gps 6214036 2017-02-01 20:30 clang/bin/llvm-ar
Content within should be identical. It's just the file ordering and
owner bits that are different. This shouldn't matter.
MozReview-Commit-ID: HOzNXAd7xwq
--HG--
extra : rebase_source : 92650cbd1869b744a5f6a1d3534fb512f85b32d1
If a CC takes too long (around 50 slices) or gets interrupted by a GC,
we have to finish it synchronously, which can cause a big pause. This
patch tries to avoid that by eagerly increasing the slice budget the
longer a CC goes on. It linearly increases the slice time from 5ms to
40ms as we approach the halfway point of a CC (1 second), matching GC
pauses, and then leaves it at 40ms.
MozReview-Commit-ID: 8TKZ0ZuxsUA
--HG--
extra : rebase_source : 2c46e56ecaa47242177d8cce53a208f08f5cabe2
For signing, pykey.py delegates to 3rd party libraries. One of these libraries
expects hash algorithms to be specified in the form "SHA-256" whereas the other
expects "sha256". Consumers of pykey shouldn't need to be aware of this detail.
This patch introduces constants HASH_SHA1, HASH_SHA256, etc. and changes pykey
to determine which string literals to use itself.
MozReview-Commit-ID: 27laM2uXMwJ
--HG--
extra : rebase_source : 9b74f486f7535671fd26c59e3e9cc3b4459f15e0
The call that's causing the crash seems to be [1], that is, we're trying to
recreate frames for the root element, which should always have a frame created
at the initialization of the PresShell.
So the function I removed in that bug had something like the following:
if (!mDidInitialize) {
// Nothing to do here. In fact, if we proceed and aContent is the
// root we will crash.
return NS_OK;
}
Which PostRecreateFramesFor doesn't guard against (because I thought it was not
needed, per tryserver results).
Sounds a lot like we do need that check, though I'd like to have a testcase
where it happens :(
[1]: http://searchfox.org/mozilla-central/rev/3dc6ceb42746ab40f1441e1e659ffb8f62ae78e3/layout/base/nsCSSFrameConstructor.cpp#2420
MozReview-Commit-ID: Lh6SohNmmI6
--HG--
extra : rebase_source : 5b7076f86d41f5489e47ca16ac2f3620812ee9e8
Similar to the other unload and load events during a page load,
the hashchange event should only be handled if the event's target
document is the current window.
MozReview-Commit-ID: F1LMBh5Cy4A
--HG--
extra : rebase_source : 668fd6946067989e7e732b24baf6de2e85541f21
originalTarget seems to be outdated and not used anymore for each
navigation related event. But target is, and as such handleEvent
has to make use of that instead.
MozReview-Commit-ID: AN2H1PbCt7A
--HG--
extra : rebase_source : fbead2b5b802454f0e288fb9696db5d422e46b50
This is a re-land of 9900d421e24e, which was backed out.
r=qdot,haik
MozReview-Commit-ID: FjugGCVWS8T
--HG--
extra : rebase_source : 7913a74a7bac9df09f8fc8e923384b5ac2569400
We can early return to call MayHaveAnimations() (and it should be fast) since
we set the flag in EffectSet::GetOrCreateEffectSet(),
MozReview-Commit-ID: 2UfWVVi6nY5
--HG--
extra : rebase_source : 97e98bf1fb9e725a107ed3200b95921375bfb637
Remove reading of "~/Library/Caches/TemporaryItems" from level 3 and update
sandboxing filesystem test to check ~/Library/Caches/TemporaryItems readability.
MozReview-Commit-ID: 6EMzH7brSnp
--HG--
extra : rebase_source : f97b5625da2abda73decc969fc581c2bf858183f
Add two tests to testInputConnection that record the sequence of
composition events during editing, and check that the sequence is what
we expected.
The first test makes sure that we reuse the current composition on the
Gecko side when setting composing text; otherwise the Facebook comment
box behaves incorrectly.
The second test makes sure that we can move the cursor inside the
current composition, to fix this particular bug.
* Include the type of the editor (input, textarea, contentEditable,
designMode) in BasicInputConnectionTest, so we can work around the
differences in behavior among the different editor types.
* Add timestamps to key events, because lack of timestamps was
triggering a crash when running testInputConnection.
Update the composition when setting/removing spans, so that we update
the selection/cursor during a composition. However, we must limit any
updating to the current composition only (as indicated by the
keep-current-composition flag), because the Facebook comment box behaves
incorrectly if we repeatedly start and end new compositions.