1340995 - [Mortar] Pressing copy combination key under form text input causes character typed unexpectedly

Status: RESOLVED FIXED

(Firefox :: PDF Viewer, defect)

Description

[KM Lee [:rexboy] (inactivate after Sep. 22)]

STR:
1. open a PDF with form input.
2. focus on a text input.
3. press copy combination key (e.g. command+c under mac or ctrl+c under windows)

expected:
Nothing happened.

Actual:
A character c is inputed into the text input.

After some discussion we think this is better fixed from runtime side. ni? ya-chieh.

Comment 1

[Ya-Chieh Wu (inactive)]

Assign myself to this to keep this bug in my list.

I am thinking that we probably do some wrong in PPB_InputEvent_GetModifiers.

Comment 2

[Ya-Chieh Wu (inactive)]

Quick update about this bug. 
I found that cmd +c/v/a… are firing as keypress event in Firefox and pdfium uses keypress event to render character inside the form. That's why we get an extra 'c' showing while press cmd+c in pdf form.

Comment 3

[Ya-Chieh Wu (inactive)]

I checked the keyboard shortcuts[1] on MDN and there are "cmd/ctrl + j/f/g/a/x/c/v/z/y".

Here are the results when the focus is in the text box of pdf form :

  Chrome:
    none of "cmd/ctrl + j/f/g/a/x/c/v/z/y" get rendered but Chrome doesn't seem to have much consistency on which get rendered which doesn't not.  For example "cmd/ctrl + i" get rendered but "cmd/ctrl + 6" ** doesn't ** get rendered.  

  Firefox:
    we have all of them get rendered.



I think we have three ways to handle this issues.
  (1)We only prevent "cmd/ctrl + j/f/g/a/x/c/v/z/y" get rendered so for example, we get "6" rendered when we press "cmd/ctrl +6".
  (2)We prevent all charCode being rendered if cmd/ctrl's flag is true.
  (3)We leave it as what it is now which will render all charCode even if cmd/ctrl's flag is true.

Either one of these three ways has better consistency than Chrome. 
I am up to (2) because I inspected our search box in Firefox and I found out that when the control bit is set, Firefox doesn't render anything in search box.

Hey Evelyn, how do you think about this? any feedback? thanks in advance.



[1] https://developer.mozilla.org/en-US/docs/Tools/Keyboard_shortcuts

Comment 4

[Ya-Chieh Wu (inactive)]

Note: The three solutions which I described in Comment 3 will only impact rendering characters in text box of pdf form. If there is a keyboard shortcut being pressed, we won't change any shortcut action.

Comment 5

[Evelyn Hung]

Thanks for the information. I vote for (2) too as I can't think of any case that we might break. Let's go for it. Thanks!

Comment 6

[Ya-Chieh Wu (inactive)]

Attachment: 0001-Bug-1340995-pdfium-skip-to-render-key-in-form-when-t.patch

To sum up:
KeyboardInputEvent::GetCharacterText is called when plugin receives a keypress event which is used to render characters in form. We prevent the plugin to get the characters if "Control" or "Meta" is being pressed together with other keys. btw this won't change any shortcut actions as we mentioned this before on above comments.

Comment 7

[Ya-Chieh Wu (inactive)]

result of try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=41f6df5b9eee2cc511a64f953f82b928a49e92e0&selectedJob=90891239

Comment 8

[Ya-Chieh Wu (inactive)]

Attachment: 0001-Bug-1340995-pdfium-skip-to-render-key-in-form-when-t.patch

result of try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=361f6ab7f0de124a9eaa8f874e6a404c3ecf00b2

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ac609288dd94
[pdfium] skip to render key in form when the key is being pressed with Control or Meta. r=ehung.

Comment 10

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/ac609288dd94