Currently, KeyboardLayout doesn't support chained dead keys because probably, the initial developer didn't expect there are such keyboard layout. Additionally, if we'd try to handle them with KeyboardLayout, it'd need to create too big and too complicated table at loading such keyboard layout. It's really nightmare. Therefore, this patch takes different approach.
Currently, when WM_(SYS)KEYDOWN is received, KeyboardLayout (and NativeKey) respects following WM_(SYS)CHAR. Similarly, this patch makes KeyboardLayout respect WM_(SYS)DEADCHAR when it handles dead key. If WM_(SYS)KEYDOWN is followed by WM_DEADCHAR, that means that the key press is in a dead key sequence and not finishing the existing dead key sequence. Therefore, when WM_(SYS)KEYDOWN is followed by WM_(SYS)DEADCHAR, KeyboardLayout activates dead key sequence.
For supporting dead key chain, this patch makes KeyboardLayout::mActiveDeadKey and KeyboardLayout::mDeadKeyShiftState arrays. When dead keydown message is received, KeyboardLayout appends an item to each of them. (I.e., when the array is not empty, it's in a dead key sequence.)
When WM_(SYS)KEYUP is received, KeyboardLayout checks if it's in mActiveDeadKey. If it's included in the array, it initializes NativeKey as a dead keyup event.
Otherwise, when non-printable key (probably) is received in a dead key sequence, KeyboardLayout doesn't handle it as a part of the dead key sequence. For example, a modifier key may be pressed for next key. (Even if the keyboard layout maps text input to a non-printable key, we can ignore them because such key's KeyboardEvent.key value should be decided only with the virtual keyboard.)
MozReview-Commit-ID: 9n8B0YYuKCO
--HG--
extra : rebase_source : d18ca896829274d35cc8b7744c5e1645a9e78784
Currently, when selection is collapsed at an empty text node, the behavior of each major browser is different.
When you remove the last character of non-empty text node followed by empty text nodes, Chromium removes all following empty text nodes. However, Edge never removes empty text nodes even when selection is collapsed at an empty text node.
With this patch, our behavior becomes same as Edge. I think that we should take this for keeping backward compatibility since Gecko never removes empty text nodes. So, in other words, this patch makes Backspace key press at an empty text node modify the preceding non-empty text node.
When you remove the first character of non-empty text node preceded with empty text nodes, Edge removes all preceding empty text nodes. However, Chromium and Gecko keeps previous empty text nodes than caret position. So, we should keep current behavior for backward compatibility. In other words, this patch makes Delete key press at an empty text node modify the following non-empty text node and keep current behavior.
The fixing approach of this is, making WSRunObject::PriorVisibleNode() and WSRunObject::NextVisibleNode() ignore empty text node. This should make sense because empty text node is not a visible node. (On the other hand, when the DOMPoint has a null character, it should treat as visible character. That is visible with Unicode codepoint.)
MozReview-Commit-ID: 11YtqBktEvK
--HG--
extra : rebase_source : 70fa858866cc768179c1ca6a869e1a5c7cfe6e1a
Showing unblocking icon when the tab's media is blocked, and hide the icon when user clicks unblocking icon or opens that tab.
MozReview-Commit-ID: LHxop9qL0uf
--HG--
extra : rebase_source : 57070ab5a3e60561c48f6330dbd26f3ecf52f93e
Add the new svg for unblocking icon.
See bug1308399 for more UX details.
MozReview-Commit-ID: 6AYXJsFRQTh
--HG--
extra : rebase_source : 8009f1dbefc4e1b7e480e2eb8bafeefa3bc2d4bc
We need to notify tabbrowser about media-blocking so that we can show the unblocking tab icon.
See bug1308399 for more UX details.
MozReview-Commit-ID: E25lEhZLCZk
--HG--
extra : rebase_source : dcb6cb520bb0983010dfcc728f7251994a886612
Adds serialization of native print settings values so
that correct page size, scaling, orientation are sent
to the child after the print dialog is displayed.
Changes the Mac print dialog code to load native
print settings from the "print.macosx.pagesetup-2"
pref and ignore what is passed in.
Overwrites the scaling percentage specified in
the print dialog when "Ignore Scaling and Shrink to
Fit Page Width" is checked.
Scaling on Nightly (remote printing) needs more work
to be done in a follow up bug.
MozReview-Commit-ID: B12ZeHuiYFJ
--HG--
extra : rebase_source : baa2a5865b29db8914fca1242af59674f9630c8e
getSelectedTab() specifies that it can return null "if we're doing a
session restore after a crash and Gecko isn't ready yet". This seems
to occasionally be happening, resulting in crashes.
(What isn't clear is why this would be happening more regularly in 51,
it's possible some completely unrelated changes are either making
the rendering of TopSites faster, causing this call to be made earlier,
or session restore has simply gotten slower. We have also had a
crash spike recently due to library loading issues, which would
likely further exacerbate the whole issue.)
MozReview-Commit-ID: GLFOoXFrAkj
--HG--
extra : rebase_source : e47922ad2b0aa9dc795f0efc1ea477a9805bd4f1
The circular ripple is only available on API >= 21. We can fallback to a different solution
for older devices, see following patch.
MozReview-Commit-ID: C0aBqsKsuZ5
--HG--
extra : rebase_source : ae5139daca4a61c1dfe78bdca7d686494d36d482
extra : source : 34e9726d1c21fa1d998f8469175e8b91d849b7e7
The ripple added using selectableItemBackgroundBorderless is scaled to the actual View area.
By rearranging our margins+padding we are able to make the empty space around the menu button
part of its padding, which results in a more naturally sized ripple. Without this
patch the circular ripple is tiny and looks odd.
MozReview-Commit-ID: 3jHWiubMtDD
--HG--
extra : rebase_source : 1c5a5f81db1c7eff45145a91b37197eef0a118f4
extra : source : 60235315c78c56655049c6e552a9c25085f1a4e4
Giving '0' (literal zero) to nsCOMPtr is now ambiguous, as both
nsCOMPtr(decltype(nullptr)) and nsCOMPtr(T*) could be used.
In any case, our coding standards mandate the use of 'nullptr' for pointers.
So I'm changing all zeroes into nullptr's where necessary.
MozReview-Commit-ID: LXiZTu87Ck6
--HG--
extra : rebase_source : f9dcc6b06e9ebf9c30a576f9319f76a51b6dc26f
Just a mechanical find/replace of all zero pointers, before the next patch.
MozReview-Commit-ID: DSzSZunAXWu
--HG--
extra : rebase_source : a5a9a064335254a7456a7ec48805c4ec08fd18af
* Compress docker images with zstd
* Removed need for context.tar from decision task
* Index images by level rather than project
MozReview-Commit-ID: 4RL4QXNWmpd
--HG--
extra : rebase_source : 677d8030a15af3288866a70fc648a10b22c396a3
This allows artifact builds to load the new compressed native libraries correctly,
without requiring build config changes.
MozReview-Commit-ID: 3xZzoV3wFda
--HG--
extra : rebase_source : 5fffe02efc38af9024ca72654153deed3c4ef757
Many tests that result in throwing errors, amongst those many type-
and platform checks, are repeated throughout the Marionette code base.
This patch centralises the most common of these, typically reducing
consumer calls from three to one line.
Example usage:
assert.defined(cmd.parameters.value);
assert.postiveInteger(cmd.parameters.value,
error.pprint`Expected 'value' (${value}) to be a signed integer`);
// InvalidArgumentError: Expected 'value' ([object Object] {"foo": "bar"}) to be a positive integer
MozReview-Commit-ID: BHOaDazeGer
--HG--
extra : rebase_source : 1d35c10e29d4fd536829e9714ae65bcd14ad21f8
Daosheng Mu
Daisuke Akatsuka
Masayuki Nakano
Carsten "Tomcat" Book
Wes Kocher
Alastor Wu
Matthew Wein
Haik Aftandilian
Dustin J. Mitchell
Andrzej Hunt
Shane Caraveo
Andrew Swan
Manish Goregaokar
Gerald Squelart
Jonas Finnemann Jensen
Henrik Skupin
Tom Tromey
Mark Banner
J. Ryan Stinnett
Ralph Giles
Andreas Tolfsen
Jared Wein