This patch adds a `mozIStorageConnection::defaultTransactionType`
attribute that controls the default transaction behavior for the
connection. As before, `mozStorageTransaction` can override the default
behavior for individual transactions.
MozReview-Commit-ID: IRSlMesETWN
--HG--
extra : rebase_source : fc63af108bb246bc096cb9ef7c13b41fabba5563
On Android, GeckoEditableSupport has already dispatched eKeyDown event and
eKeyUp event even during composition. I.e., the pref which will be enabled
by bug 354358 has already been set to true only on Android.
On the other hand, GeckoEditableSupport does not dispatch them if content
listens to "input", "compositionstart", "compositionupdate" or
"compositionend". So, different from the other platforms, we cannot test
this behind pref ("dom.keyboardevent.dispatch_during_composition") even in
Nightly.
Therefore, this patch enables new behavior only when it's Nightly build or
early Beta. And sets mKeyCode and mKeyNameIndex of the dummy KeyboardEvents
to NS_VK_PROCESSKEY and KEY_NAME_INDEX_Process.
MozReview-Commit-ID: Fuy0Ir2xiO5
--HG--
extra : rebase_source : fade31954eaa1be8b7592977095ba8aebdd75104
First of all, TextInputHandler::HandleKeyDown() dispatches an eKeyDown event
before sending IME. This is different behavior from Gecko on the other
platforms and it means TextInputHandler does not know if the eKeyDown event
will be handled by IME. Therefore, we need to make TextInputHandler dispatch
an eKeyDown event dispatch when it needs to dispatch another event. Therefore,
this patch makes TextInputHandler not dispatch an eKeyDown even from
its HandleKeyDown() unless it's already has composition (because if it's
already had composition, any eKeyDown event except modifier keys should be
marked as "processed by IME" for compatibility with the other browsers).
For dispatching eKeyDown event only once for a native keydown event,
this patch implements TextInputHandlerBase::MaybeDispatchCurrentKeydownEvent()
to check whether eKeyDown event has already been dispatched for the event
and if it's not so, dispatches eKeyDown event.
Note that on macOS, dead keys are implemented as IME. However, we need to
treat dead keys as is. Therefore, if current keydown event is a dead keydown
event, MaybeDispatchCurrentKeydownEvent() should NOT mark dispatching
eKeyDown event and its following eKeyDown event as "processed by IME".
MozReview-Commit-ID: 7epk8wdAznd
--HG--
extra : rebase_source : 4f4e23a8cc5005d8f0da3c35910eba30f8777e6b
Currently, IMContextWrapper doesn't dispatch eKeyDown event and eKeyUp event
if it's handled by IME. However, for conforming to UI Events, it should
not eat given keyboard events completely.
This patch makes IMContextWrapper dispatches eKeyDown event or eKeyUp event
before dispatching first event of composition events or content command
event.
MozReview-Commit-ID: H2jHpViTH5Q
--HG--
extra : rebase_source : 4129620126a34e27af1503e7c4652bb09c7e9bb6
For conforming UI Events spec, KeymapWrapper::InitKeyEvent() should initialize
mKeyCode and mKeyNameIndex with NS_VK_PROCESSKEY and KEY_NAME_INDEX_Process if
given keyboard event has already been handled by IME.
For making it know if given keyboard event has been handled by IME, this patch
adds additional bool argument to it and its callers.
Note that this patch changes keyCode value and key value of "keydown" event if
it's fired before "compositionstart" since Chromium does so on Linux.
MozReview-Commit-ID: FC3tfyeeopU
--HG--
extra : rebase_source : 9c88967b8e2a5539023deb1277ae8704418dfd0d
On Windows, VK_PROCESSKEY key message is sent if the key event is handled by
IME (in IMM mode or IMM-IME). Therefore, we can set
WidgetKeyboardEvent::mKeyCode to NS_VK_PROCESSKEY and
WidgetKeyboardEvent::mKeyNameIndex to KEY_NAME_INDEX_Process simply when
we receive VK_PROCESSKEY.
MozReview-Commit-ID: 9B8Q7rwfXYD
--HG--
extra : rebase_source : a15105e3b6acf1f1911a8299911353dc4179e2c0
When native key event is handled by IME, we should set keyCode to 0xE5 (229,
VK_PROCESS of virtual keycode of Windows) for behaving same as the other
browsers.
This patch declares it same as other keyCode values.
MozReview-Commit-ID: 666bB1qOEgv
--HG--
extra : rebase_source : 8edcc49aab537240fb696b010e642848a6d439d4
geckodriver uses log 0.4, but it depends on a version of hyper that
uses log 0.3.
Previously this meant that geckodriver's logger could only see
messages from crates using log 0.4, and had no access to messages
from hyper or other crates using log 0.3. However, log 0.3.9 added
interoperability so that programs built with a mix of log 0.3 and
log 0.4 can again display messages from all crates.
This patches geckodriver::logging to contain a whitelist of logged
targets we care about. Currently this list includes geckodriver,
mozprofile, mozrunner, mozversion, and webdriver. This will revert
us to the behaviour prior to upgrading hyper to use log 0.3.9,
and would be similar to the old implementation we had for filtering
logs we had when geckodriver used slog.
Thanks-to: Matt Brubeck <mbrubeck@mozilla.com>
MozReview-Commit-ID: 6Xj0k6VD1dQ
--HG--
extra : rebase_source : 7a5aee1642b94516eedc1ca25b722e2868d0983b
The extensions.shield-recipe-client.api_url preference was
replaced with app.normandy.api_url in bug 1436113. There are
multiple automation tools in the tree that target out-of-tree
release channels and removing the old preference would break these.
This patch re-adds the old preference with a note of when it was removed.
MozReview-Commit-ID: HhTfRFkRQTC
--HG--
extra : rebase_source : ec726c528b57e197a34e3e094c1c4bfe5d23da55
The datareporting.healthreport.about.reportUrl preference was removed
in bug 1352497, but there are multiple automation tools in the tree
that target out-of-tree release channels.
This patch restores the preference with a note that it was removed
in Firefox 59.
MozReview-Commit-ID: Lg8bxoiIfxn
--HG--
extra : rebase_source : ce3744baf37b30210239a5b840ee9fb1f7dc38f4
This is in preparation for adding the rapid add/remove test from bug 1295761.
Changes:
- Added `tree.exists(item)` to fix an issue where `selectTreeItem()` was caled for an item that did not exist and then waited for an `store-objects-updated` event. It only ever received this event due to errors when writing tests.
- Renamed `StorageUI.onUpdate()` to `StorageUI.onEdit()` and changed it's event name to `store-objects-edit`.
- Changed tests to use `store-objects-edit` where appropriate.
MozReview-Commit-ID: IAem8Penrf9
--HG--
extra : rebase_source : b818f8647958ad0688954fe5028f8d57aa119c33
Also remove duplicate import from the XMLMonoPrint sheet (unnamed default sheets
stay applied when switching to alternates, only named are unapplied).
Additionally fix some regressions from bug 379683:
* top-level collapsed and uncollapsible elements weren't monospaced in monospace
style.
* top-level uncollapsible elements weren't indented.
* there was an extra space between PIs and their expander control.
Based on prototype by bgrins.
MozReview-Commit-ID: 2Pikm41FMWY
--HG--
extra : rebase_source : a8fb7dd9f40a267e93d50342c51728dcc98c4918
TryOptimizeToImageLayer was renamed/repurposed in c0654f3b986d, but
the old declaration was never removed.
MozReview-Commit-ID: 52JJofv3u3t
--HG--
extra : rebase_source : 959bee3f9c1bbab9f4b456fcfd4d8fe1ff1655f7
J. Ryan Stinnett
Jonathan Kingston
Cosmin Sabou
Kit Cambridge
Kartikaya Gupta
Dão Gottwald
David Keeler
Thom Chiovoloni
Glenn Watson
Sylvestre Ledru
Mark Banner
Gabriele Svelto
Anthony Ramine
Simon Sapin
Masayuki Nakano
Andreas Tolfsen
Mike Conley
Xidorn Quan
Michael Ratcliffe
Amy Chan
Emilio Cobos Álvarez
Ian Moody
Austin Lasher
Jan Odvarko