In the failing case, the context menu is basically appearing over <body>
instead of the image. In that case we don't show the 'view image' option
and don't have a URL to use to open the image, which means we try and
do a security check for the load of '', which fails, and we don't get
a new load on which to run the rest of the test.
My guess is this is happening because if the image hasn't loaded yet
by the time we run the code, it takes up no space at all, and a mouse
event at its coordinates only 'hits' the body.
We can avoid that by givin the element width and height.
MozReview-Commit-ID: kU2IoYTqeE
--HG--
extra : rebase_source : f381a33b62bc910f3becf69b4971b56e57c33e5f
This is a one-line fix. about:rights doesn't take query parameters, isn't interactive, and so making it linkable should be fine for uplift.
MozReview-Commit-ID: CQwh6SPLARf
--HG--
extra : rebase_source : 278b97a21a397c2d6f4cc7fc4da29e12ee27adb9
Going forward there will be just one highlights item/layout with an optional image.
MozReview-Commit-ID: BmtUTtanjJr
--HG--
extra : rebase_source : e80edea42af9bdc9c3a79b3bd9588d0a91f8faf7
The UNION operator requires the two result sets to have the columns in the same order.
MozReview-Commit-ID: JRtw0LDZ5ib
--HG--
extra : rebase_source : a2cc6b2a9190cf9fb8ec75351446e0a91e613710
Now, NativeKey::HandleCharMessage() has almost same code, one is for dispatching eKeyPress event for non-printable keys or printable keys when one of Alt or Ctrl key is pressed, the other is for printable keys when Alt or Ctrl key is pressed.
The difference of them is, the former block removes Alt state and Ctrl state for handling AltGr key. When AltGr key is pressed, both Alt and Ctrl state are true. However, EditorBase treas keypress events whose altKey or ctrlKey is true as non-printable key event. Therefore, we need to set these modifier state to false when AltGr key is pressed and the key causes some text.
Note that as far as we know, when a key press with AltGr doesn't cause any characters, WM_CHAR isn't generated. Therefore, we don't need to check with complicated logic if the key event is actually inputting a character.
MozReview-Commit-ID: BRNWfICvkSm
--HG--
extra : rebase_source : 3b8a2aaeb4c53be1567f7a8d17dfef1af90406dd
Current shortcut key handling is really difference from what we did before struggling with "key hell". Therefore, remaining hacks for charCode in NativeKey::HandleCharMessage() are not necessary because they are for old code.
MozReview-Commit-ID: 3hvsBOiJ6VV
--HG--
extra : rebase_source : 7387fc89930f9b15d5d01612eb4a7a5726924bcd
This patch makes NativeKey::HandleCharMessage() stop dispatching eKeyPress event when the message is inputting a control character. NativeKey::HandleCharMessage() runs following cases:
1. WM_KEYDOWN followed by a WM_CHAR message whose wParam is not a control character causes inputting printable characters.
2. WM_CHAR message is received without WM_KEYDOWN message.
So, when HandleCharMessage() is called for a control character, it's unusual case. E.g., another application sends only WM_CHAR message with a control character.
On the other hand, Gecko is the only browser which dispatches "keypress" event even if pressed printable key doesn't cause inputting any characters. And such "keypress" event is used for shortcut key handling and some default action handling. So, even if we stop dispatching eKeyPress event from HandleCharMessage(), it shouldn't affect most users.
Note that this patch does NOT change the behavior when the user inputs a control character with usual keyboard layout such as Ctrl+A of en-US keyboard layout because DispatchKeyPressEventsWithoutCharMessage() dispatches eKeyPress event in such cases.
This patch also adds a lot of tests with Ctrl or Alt state for detecting regressions.
MozReview-Commit-ID: KUNqTp7RDSc
--HG--
extra : rebase_source : f91e37b0b82a8e8a95444a08f6d3101f14fadc50
Currently, Enter and Backspace keys are handled without following WM_(SYS)CHAR message. However, older code needs hack for them for avoiding conflict with Ctrl+J vs. Ctrl+Enter, etc.
So, we can get rid of them now. And when a keydown causes inputting a control character, NativeKey should handle it with keyboard layout (i.e., without following char message(s)).
MozReview-Commit-ID: 6bVuK0BzFbx
--HG--
extra : rebase_source : 08ff45c1990ef8f3ed7703c69b2dc22e5f1dd6f5
Currently, NativeKey::HandleCharMessage() is only a public method and it takes any char message. However, when it's called outside of NativeKey, it should work only with NativeKey::mMsg.
Therefore, we should make current HandleCharMessage() a private method and create new overload method which doesn't take MSG as an argument.
MozReview-Commit-ID: LowV2FUmR3U
--HG--
extra : rebase_source : 271c61515752cf1ea56cf12c4f7ef6f1a90c9cac
NativeKey shouldn't include characters which are provided by WM_SYSCHAR message or WM_DEADCHAR message into mCommittedCharsAndModifiers.
MozReview-Commit-ID: Ax1BmO5wTy0
--HG--
extra : rebase_source : 5d7d1735a783213f7c6a47cca0cadb1d4c5104c0
For consistency with IsPrintableCharMessage(), IsFollowedByNonControlCharMessage() should be renamed to IsFollowedByPrintableCharMessage().
MozReview-Commit-ID: CBJFPO4FZej
--HG--
extra : rebase_source : f5d677743be35a3bb5fca35e7658e907aa46dbcb
Currently, NativeKey::IsFollowedByNonControlCharMessage() returns true only when the first char message is a printable char message. Although, I don't know actual cases coming printable WM_CHAR message after non-printable char message, i.e.,
1. WM_SYSCHAR or WM_DEADCHAR
2. WM_CHAR for a printable character
or
1. WM_CHAR with a non-printable character (a control character)
2. WM_CHAR with a printable character
, we should make it return true because when one or more characters are being inputted, we should ignore non-printable char messages and handle printable char messages in the path handling text input.
MozReview-Commit-ID: 1v7v5mCRFCP
--HG--
extra : rebase_source : f82f7b77376450168bad34be031164ecf7338621
Currently, NativeKey::IsPrintableCharMessage() returns true if given message is WM_CHAR or WM_SYSCHAR. However, WM_SYSCHAR never causes inputting any character and even if WM_CHAR has a control character (i.e., non-printable character), it returns true.
MozReview-Commit-ID: IoU5F06WImz
--HG--
extra : rebase_source : c48f424f3d2960e6e9ceaa6d2fb09952ca634c3f
This guarantees that the runnable will be processed before shutdown leak checking.
MozReview-Commit-ID: B89AcDUWb3y
--HG--
extra : rebase_source : bfbd311fba367c1856cc5d972e6e999ccd4de1ac
Since I want to use more agent's functions in MediaElement and I don't think these functions need to be exposed on IDL level. (for other languages binding)
Therefore, I want to use AudioChannelAgent directly in MediaElement.
MozReview-Commit-ID: 43FvDeLpZPt
--HG--
extra : rebase_source : 78741d791eb66cfb6223866ce823f217e3438fdb
Kartikaya Gupta
Benjamin Bouvier
Alexandre Poirot
Gijs Kruitbosch
Mark Goodwin
Sebastian Kaspari
Masayuki Nakano
Henry Chang
Markus Stange
Phil Ringnalda
Alastor Wu
Brian Grinstead
Sebastian Hengst
Dale Harvey
Thom Chiovoloni
Carsten "Tomcat" Book
Matt Woodrow