The browser-chrome self-test files now use the setExpectedFailuresForSelfTest function to specify the exact number of assertion failures that will be triggered. Also, most failures are now intercepted when specifying the "fail-if" property in a "browser.ini" manifest, while previously only those triggered using the "ok" function were intercepted. This allows re-enabling several browser-chome self-tests.
MozReview-Commit-ID: DlDjWaJPfvH
--HG--
extra : rebase_source : 498914c84ab69dd484fb5487ad9967073c331fd3
Several mochitests call `assertSnapshots`, which prints a reftest-like output
for use with the reftest analyzer. Update these lines to check failure patterns
before printing, like the regular assertion methods do.
MozReview-Commit-ID: CfChoar7bp8
Several mochitests call `assertSnapshots`, which prints a reftest-like output
for use with the reftest analyzer. Update these lines to check failure patterns
before printing, like the regular assertion methods do.
MozReview-Commit-ID: CfChoar7bp8
IMEContentObserver notifies IME of 3 notifications at most when editor is changed.
The order is:
1. text change (with merged range if 2 or more change occurred during an edit transaction)
2. selection change (only the latest selection change. other changes occurred before that during an editor transaction are ignored)
3. position change (scrolled, resized, window moved, etc)
This does not check the behavior in designMode because some operation in testWithHTMLEditor() causes unexpected behavior, e.g., moving focus. It *might* be bug of design mode. However, it doesn't matter for this bug. The important thing of this bug is, there should be automated tests for IMEContentObserver. And fortunately, IMEContentObserver does not check the type of editor. So, it's enough to test only contenteditable element for HTMLEditor at least for now. Therefore, I gave up to test it in designMode for now.
MozReview-Commit-ID: 7L6ZlbVMU2P
--HG--
extra : rebase_source : 8282fe7aa2f4d405f2576f05d46b60b044223855
This patch allows the use of the flag '--jscov-dir-prefix' for mochitest plain tests to enable code coverage collection with the JS Debugger. It also enables the mochitest-plain tests for the linux64-jsdcov build platform.
MozReview-Commit-ID: 6RqMEZ1I0D7
--HG--
extra : rebase_source : 351754541801f69f7c54807f6bdd3a3d1baf9222
This was tricky because synthesizeMouse would compute the incorrect
coordinates if the requested event target was in a sub-frame. With this patch,
we deal correctly with sub-frames.
MozReview-Commit-ID: KpUKxFXKMrl
--HG--
extra : rebase_source : 08dbbd1abe04886ac4fe14fad11312ba0f63873b
Checking window.Components is a heuristic already used at the top of the
file for initializing _EU_C*, and it seems to work on try.
MozReview-Commit-ID: 3nbFAEJMY7h
Now, NativeKey respects following WM_CHAR message. Therefore, we can create a test for bug 1293505 which a function key causes a printable character.
Additionally, bug 1307703 is now fixed by the previous patch. So, let's add automated test for it too.
Finally, now, I found a way to test with some keyboard layouts which are not available on old Windows. Therefore, we should add automated tests for bug 1297985 too.
MozReview-Commit-ID: IqCEPbPYrcQ
--HG--
extra : rebase_source : 451d0264f1180cae7d7035a498f1c13416d53246
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
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
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 removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Native IME handler may want to query content relative to start of selection (or composition if there is it). Additionally, in e10s mode, insertion point in actual content may be different from the cache in parent. Therefore, in some cases, it does make sense to query content with offset relative to start of selection or composition.
This patch implements it simply and only in non-e10s mode.
Additionally, this fixes a bug of nsQueryContentEventResult::GetOffset() which hasn't been accepted its calls even if the event message is valid (eQueryTextContent, eQueryTextRect and eQueryCaretRect).
MozReview-Commit-ID: 34I7vyTUAgO
--HG--
extra : rebase_source : d79ba0dc3e002f7691495ee1ff8bdb3854d8f6fe
VolumeMute was renamed to AudioVolumeMute in the latest draft and Chromium uses the new name. Therefore, we need to update this but Gaia uses the old name. So, we shouldn't rename on B2G until Gaia is fixed.
Note that this patch changes tests but they are not used by B2G. Therefore, just replacing with new name is enough.
Only forms.js is necessary #ifdef because the main purpose of forms.js is for B2G's IME framework. However, it's available on the other platforms if chrome needs to use it.
MozReview-Commit-ID: KSkcPbIovin
--HG--
extra : rebase_source : 4ff5d92b000599806367b002fd08aa5ae858ee4d
VolumeUp was renamed to AudioVolumeUp in the latest draft and Chromium uses the new name. Therefore, we need to update this but Gaia uses the old name. So, we shouldn't rename on B2G until Gaia is fixed.
Note that this patch changes tests but they are not used by B2G. Therefore, just replacing with new name is enough.
Only forms.js is necessary #ifdef because the main purpose of forms.js is for B2G's IME framework. However, it's available on the other platforms if chrome needs to use it.
MozReview-Commit-ID: KzLVL5Y2dIN
--HG--
extra : rebase_source : d7a70f556684cdc99989e408e0e87a04e2da43d9
VolumeDown was renamed to AudioVolumeDown in the latest draft and Chromium uses the new name. Therefore, we need to update this but Gaia uses the old name. So, we shouldn't rename on B2G until Gaia is fixed.
Note that this patch changes tests but they are not used by B2G. Therefore, just replacing with new name is enough.
Only forms.js is necessary #ifdef because the main purpose of forms.js is for B2G's IME framework. However, it's available on the other platforms if chrome needs to use it.
MozReview-Commit-ID: cq98qJnS8M
--HG--
extra : rebase_source : 98653e5427d9d4720d19011673cbb0f9cdf36f1a
This function is roughly copied from browser/base/content/test/general/head.js.
It has been widely used in browser chrome mochitests, and should be fine to
have it available to all mochitests via SimpleTest.
MozReview-Commit-ID: DhIfgJiUhXK
--HG--
extra : rebase_source : 95ab1cd6c1ab5f6c0d8f0171865722ca76b41c6e
This uses the same text as the equivalent code in browser-test.js.
MozReview-Commit-ID: 2CzZEjf8ojn
--HG--
extra : rebase_source : f64d52b1d5289db410de9d6237d35cebf6adfb32
Sebastian Hengst
Paolo Amadini
J. Ryan Stinnett
Phil Ringnalda
Andrew McCreight
Christoph Kerschbaumer
Florian Quèze
Xidorn Quan
Masayuki Nakano
Dan Banner
Geoff Brown
Stone Shih
Tomislav Jovanovic
Wes Kocher
Kartikaya Gupta
Greg Mierzwinski
Carsten "Tomcat" Book
Gijs Kruitbosch
Boris Zbarsky
Blake Kaplan
pyang
Masatoshi Kimura
Ho-Pang
Tooru Fujisawa
Kris Maglione
Aryeh Gregor
Ehsan Akhgari
Andrew Halberstadt
prakhar0409
Marcos Caceres
Rob Wu
Ryan VanderMeulen
Rob Wood
Andrew Swan
Neil Deakin
Thomas Wisniewski
Fabrice Desré
Tom Tromey
Bob Clary
Joel Maher
Matthew Noorenberghe
Xidorn Quan
Junior Hsu
Francois Marier
Jared Wein
JW Wang