This leak checker may be triggering a shutdown leak on Windows,
doesn't work with e10s, and should not be needed now that ttaubert
fixed the ++DOMWINDOW leak detector to work.
The additional GCs and CCs this patch adds used to be run as part of
cc-analyzer.js, and are needed to avoid window leaks in tests.
MozReview-Commit-ID: IzZI6h2SCr2
--HG--
extra : rebase_source : 7bacc70e9f4b41208c1ef057faf53ed3af5d2e12
These builds can be run on taskcluster to obtain per-test (JSDebugger) code coverage with the linux64-jsdcov build and overall (GCOV) code coverage with the linux64-ccov build. The linux64-jsdcov build also needed to have leak checking disabled for debug mode.
MozReview-Commit-ID: ASgrU2X7RQV
--HG--
extra : rebase_source : b2098e4d01039edd6cff37f3e6a26c2ed3d3d3ba
Unfortunately, MapVirtualKeyEx() doesn't compute ABNT C1's scan code from its virtual keycode, 0xC1. Therefore, NativeKeyCodes.js should specify 0x0056 explicitly. Fortunately, this key in physical keyboard always generates the scan code value with any keyboard layouts. Therefore, this can test new regressions as expected.
FYI: ABNT C1 key is a key in Brazilian keyboard. It's at between "ShiftLeft" and "KeyZ".
MozReview-Commit-ID: GmpnFKOsnKD
--HG--
extra : rebase_source : 197b249740056e5c4b7c6f3b556f91f50a838d52
On Windows, some keys are called "extended key". Their scan code include 0xE000. For example, Enter key in standard position is 0x001C but Numpad's Enter key is 0xE01C. Unfortunately, both of them cause same virtual keycode value, VK_RETURN. Therefore, currently, nsIDOMWindowUtils.sendNativeKey() can synthesize only one native key event of them (only non-extended key's event). Additionally, MapVirtualKeyEx() API with MAPVK_VK_TO_VSC (even with MAPVK_VK_TO_VSC_EX) don't return extended scancode value as expected.
For solving these issues, we should include scan code value to the virtual keycode value at calling sendNativeKey().
Fortunately, virtual keycode value on Windows is 0 ~ 255 (0x00 ~ 0xFF) but aNativeKeyCode of sendNativeKey() is int32_t. So, we can use upper 16 bit for specifying scan code.
This patch explicitly specifies scan code value at defining WIN_VK_* in NativeKeyCodes.js. Additionally, this patch duplicates native virtual keycode definition for Home, End, Insert, Delete, PageUp, PageDown, ArrowUp, ArrowLeft, ArrowDown, ArrowRight and Enter as WIN_VK_* and WIN_VK_NUMPAD_*. This makes automated tests can specify both positions' keys explicitly.
Finally, this patch adds some tests to test_keycodes.xul for testing KeyboardEvent.code value of those keys in both positions.
MozReview-Commit-ID: 8n1rQ71dilg
--HG--
extra : rebase_source : 8215e56ba1ed9fc54c04eb7ca037b12c3ced5c1b
These builds can be run on taskcluster to obtain per-test (JSDebugger) code coverage with the linux64-jsdcov build and overall (GCOV) code coverage with the linux64-ccov build. The linux64-jsdcov build also needed to have leak checking disabled for debug mode.
MozReview-Commit-ID: ASgrU2X7RQV
--HG--
extra : rebase_source : af40a6e582665ffcb575092586731f595a362ae4
Unfortunately, MapVirtualKeyEx() doesn't compute ABNT C1's scan code from its virtual keycode, 0xC1. Therefore, NativeKeyCodes.js should specify 0x0056 explicitly. Fortunately, this key in physical keyboard always generates the scan code value with any keyboard layouts. Therefore, this can test new regressions as expected.
FYI: ABNT C1 key is a key in Brazilian keyboard. It's at between "ShiftLeft" and "KeyZ".
MozReview-Commit-ID: GmpnFKOsnKD
--HG--
extra : rebase_source : 37f78552a1ebba6f61c38add0138b84ddef36c3e
On Windows, some keys are called "extended key". Their scan code include 0xE000. For example, Enter key in standard position is 0x001C but Numpad's Enter key is 0xE01C. Unfortunately, both of them cause same virtual keycode value, VK_RETURN. Therefore, currently, nsIDOMWindowUtils.sendNativeKey() can synthesize only one native key event of them (only non-extended key's event). Additionally, MapVirtualKeyEx() API with MAPVK_VK_TO_VSC (even with MAPVK_VK_TO_VSC_EX) don't return extended scancode value as expected.
For solving these issues, we should include scan code value to the virtual keycode value at calling sendNativeKey().
Fortunately, virtual keycode value on Windows is 0 ~ 255 (0x00 ~ 0xFF) but aNativeKeyCode of sendNativeKey() is int32_t. So, we can use upper 16 bit for specifying scan code.
This patch explicitly specifies scan code value at defining WIN_VK_* in NativeKeyCodes.js. Additionally, this patch duplicates native virtual keycode definition for Home, End, Insert, Delete, PageUp, PageDown, ArrowUp, ArrowLeft, ArrowDown, ArrowRight and Enter as WIN_VK_* and WIN_VK_NUMPAD_*. This makes automated tests can specify both positions' keys explicitly.
Finally, this patch adds some tests to test_keycodes.xul for testing KeyboardEvent.code value of those keys in both positions.
MozReview-Commit-ID: 8n1rQ71dilg
--HG--
extra : rebase_source : 0f4bb9193aa06cd7985590636b77a6e2a71ac2e4
- When one of the parameters to isDeeply is an object/function
and the other is not, isDeeply returned false. Well, isDeeply
is supposed to report an error instead of returning a value...
- Change the implementation of isDeeply to have SameValue semantics
instead of weak equality.
- Change the representation of arrays to look like an array, instead
of its default toString() value which is indistinguishable from a
string due to the lack of brackets and quotes.
- Account for missing object properties;
Distinguish them from "undefined" with the special DNE tag.
MozReview-Commit-ID: F1OJhbXcptl
--HG--
extra : rebase_source : 26091a40445064da3f87d61438bd74bbe7491363
eQueryTextRect is used by widget and eQueryTextRectArray is used by ContentCacheInChild. So, matching their result guarantees that widget can get same result both in non-e10s mode and e10s mode. So, the matching should be tested.
MozReview-Commit-ID: 6GfbyvZ9X7H
--HG--
extra : rebase_source : 12511d84cbd94b3f4edf42367a84ee45abc66d9e
This will allow developers to request a loaner for an Android mochitest job and then use
|mach mochitest| to run tests.
MozReview-Commit-ID: 4lsKGpizfH7
--HG--
extra : rebase_source : fba9adb6e2d50cc9ac27532bc91b5eb1d909d874
I noticed that if you request a loaner for a non-e10s job then run mach, it will be run with e10s
enabled. The mach command should accurately reflect the type of job that got requested. This patch
grabs the 'e10s' argument from the mozharness localconfig.json and uses that.
MozReview-Commit-ID: 4lsKGpizfH7
--HG--
extra : rebase_source : 6f7b45146bb7f3431c242d92b4206d41f7217c03
You can set attributes on a mach context by using the 'key' argument to the context_handler. Basically,
whatever gets returned by the handler when <key> is passed in, will get set (i.e cached) on the context
object for fast retrieval next time. This is a way to lazy load these attributes.
Previously I was setting functions like 'find_firefox()' on the context object, and then having the
mach_commands call that directly. But this way is much cleaner.
Now, the loaded 'mozharness_config' can be stored as an attribute on the context. Also 'find_firefox()'
is now an attribute called 'firefox_bin'.
MozReview-Commit-ID: 4lsKGpizfH7
--HG--
extra : rebase_source : af5e32e05a29b8e91d4cd0005689baa8079ec137
I had a mistake in my code that resulted in an exception being thrown when starting the
mochitest servers. However, the log just showed a timeout. It was very confusing.
After some digging, I found that there's a large try/finally block (with no except) in
runtests.py. The exception wasn't being displayed because of the finally block. This
try/finally block had an inner try/except/finally that wrapped part of the code. This
patch simply removes that inner block and dedents the 'except' clause to attach to the
original try/finally.
MozReview-Commit-ID: 4lsKGpizfH7
--HG--
extra : rebase_source : 9d55b967c8384498a4d104730a7bb91c4885bbea
In mozdevice, it's possible to pass in the path to the adb binary (rather than requiring it to be on the path). The
mochitest android options don't provide any means to set this however (even though the b2g options do). This patch
adds that option in.
This will be used by the mach environment on interactive loaners.
MozReview-Commit-ID: 4lsKGpizfH7
--HG--
extra : rebase_source : 07ad43c8fff3eb83a1eaab9ad0532cd85c4532c7
Prior to this change, SpecialPowers used the extension id to identiy
extension instances in inter-process messaging. This required that
an id be allocated from the content process side when loadExtension()
was called, but that made it impossible to test code that exercises the
code path in the AddonManager that allocates ids for extensions that do
not include an id in the manifest (it also made the loadExtension() api
clunky).
With this change, SpecialPowers allocates an internal identifier for
messaging, but this identifier is separate from extension ids.
Confusingly, we still store the actual extension id in an id property
on the object returned by loadExtension(), but there are enough tests
that reference this that it would be unnecessarily disruptive to get
rid of it so it stays for now...
MozReview-Commit-ID: G6xk1mBJJL8
--HG--
extra : rebase_source : a0891e5ba308972c35813f55274badf9edde62f7
extra : source : e8818ef3c28489e196d1db92cabf224861b693c9
This accomplishes three things:
1) Easier to use CLI when running without the benefit of testing/mochitest/mach_commands.py
2) Guarantees these arguments are mutually exclusive
3) Simplifies a bunch of logic in the test harness
The primary motivation for this change is to slightly improve the UX when running mochitest
from a taskcluster interactive loaner. However, this is more of a bandaid solution that was
easy to implement before the proper fix in bug 1293259 can be landed.
MozReview-Commit-ID: IeHBGrJ0Sji
--HG--
extra : rebase_source : ba1b7e437881e363fe0051dccd3d732221311c59
This fixes a regression from bug 1288827. It happened because I moved the logic that finds
the application path a little later on in the test harness. But there was an instance where
it was being used in the android mach command before that point.
As it turned out, we don't really *need* that value there. This patch grabs the same value
from build_obj.substs which is already an argument to the function.
MozReview-Commit-ID: 3IsI4VzEIIF
--HG--
extra : rebase_source : ceb718b265c7886b831e0378436baebf2b4e7598
