1502795 - Re-enable mirroring charCode and keyCode values of keypress event with blacklist

Status: VERIFIED FIXED

(Core :: DOM: Events, enhancement, P2)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

Similar to strict keypress event dispatching, we should have a blacklist (at least for Nightly) to enable mirroring keyCode and charCode values of keypress event by default.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e2137d5c54760c3306b570a2572638b6af759051

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=33dfdfd6992047377db31cf327132a687d65e334

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

Linux x64: https://queue.taskcluster.net/v1/task/EQIzt1gPQZuGwVpp0K3FiQ/runs/0/artifacts/public/build/target.tar.bz2
macOS: https://queue.taskcluster.net/v1/task/KM7Q8XSoRuagBZgcfmJMEg/runs/0/artifacts/public/build/target.dmg
Windows x64: https://queue.taskcluster.net/v1/task/VbTmJySFRRKnJyQZlBawRA/runs/0/artifacts/public/build/target.zip

overholt:

I roughly tested with the patched build, then, I see some problems only on Google Docs. I.e., I don't see any problems on rememberthemilk.com nor Gmail. Could you check whether shortcut keys which you usually use work fine on those services without adding blacklist? (I think that testing on a platform is enough.)

Comment 4

[Dan]

why did you mention www.rememberthemilk.com, was that one of the affected sites?

Comment 5

[Dan]

(http://rememberthemilk.com, I thought adding www. here would act as clickable link)

Comment 6

[mikebaretta]

I have confirmed that FF63 in Win64 gives a keyCode of 0 for all keys when using onKeyPress. This is why we are experiencing the bug 1478102 on our website.

Does it seem like something that can be fixed immediately?

And can you provide the steps to reproduce this error in gmail (mentioned above)?

If anyone needs more info please let me know, I am happy to assist!

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

(In reply to Daniel from comment #4)
> why did you mention www.rememberthemilk.com, was that one of the affected
> sites?

Yes, it is. See bug 1497518.

(In reply to mikebaretta from comment #6)
> I have confirmed that FF63 in Win64 gives a keyCode of 0 for all keys when
> using onKeyPress. This is why we are experiencing the bug 1478102 on our
> website.
> 
> Does it seem like something that can be fixed immediately?

We don't have fixed schedule of releasing new behavior since we need to wait some web sites to fix some wrong feature detection or UA name check.

Comment 8

[mikebaretta]

Any reason why you wouldn't simply re-enable keyCode to work properly with onKeyPress? I don't understand the purpose of setting keyCode to 0 for all keys.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

(In reply to mikebaretta from comment #8)
> Any reason why you wouldn't simply re-enable keyCode to work properly with
> onKeyPress? I don't understand the purpose of setting keyCode to 0 for all
> keys.

Since some web apps are actually broken.

And I don't understand why some web developers think that keyCode of keypress events should be set differently from keyCode of keydown/keyup since the value becomes Unicode code point value which is set to charCode.

Comment 10

[Andrew Overholt [:overholt]]

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #3)
> I roughly tested with the patched build, then, I see some problems only on
> Google Docs. I.e., I don't see any problems on rememberthemilk.com nor
> Gmail. Could you check whether shortcut keys which you usually use work fine
> on those services without adding blacklist? (I think that testing on a
> platform is enough.)

Some keys some to work in RTM but 't', for example (create a new task) does not.

Comment 11

[Dan]

Do you mean key pressed/released by "keydown/keyup"?

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

(In reply to Andrew Overholt [:overholt] from comment #10)
> (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #3)
> > I roughly tested with the patched build, then, I see some problems only on
> > Google Docs. I.e., I don't see any problems on rememberthemilk.com nor
> > Gmail. Could you check whether shortcut keys which you usually use work fine
> > on those services without adding blacklist? (I think that testing on a
> > platform is enough.)
> 
> Some keys some to work in RTM but 't', for example (create a new task) does
> not.

Thank you. I verified that even in their Beta channel.

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

Attachment: Bug 1502795 - Set keyCode or charCode of keypress event whose value is zero to the other's non-zero value by default again unless dispatched on known broken web apps

This patch re-enables the new behavior of bug 1479964, to set keyCode or
charCode of keypress event whose value is zero to the other's non-zero value.

However, some web apps are still broken with the new behavior.  Therefore,
this patch adds a blacklist to keep using our legacy behavior in some specific
web apps.

Note that Google Docs, Gmail and Remember The Milk are reported as broken.
However, I don't see any broken shortcut with Gmail.  Therefore, this patch
adds only Google Docs and Remeber The Milk into the blacklist.

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

(In reply to Andrew Overholt [:overholt] from comment #10)
> (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #3)
> > I roughly tested with the patched build, then, I see some problems only on
> > Google Docs. I.e., I don't see any problems on rememberthemilk.com nor
> > Gmail. Could you check whether shortcut keys which you usually use work fine
> > on those services without adding blacklist? (I think that testing on a
> > platform is enough.)
> 
> Some keys some to work in RTM but 't', for example (create a new task) does
> not.

Ah, I'm sorry, I realized that you wrote it in the description of bug 1497518 when you filed the bug.

Comment 15

[mikebaretta]

Please realize that even if you set keyCode or charCode of keypress event whose value is zero to the other's non-zero value, you will still have some problems with bug 1478102.

The issue is that Command and Navigation keys must be reverted to a non-event as they were with FF62. Currently with FF63 Command and Navigation keys trigger an onKeyPress event which causes a problem. In GC and IE the Command and Navigation keys do not trigger an onKeyPress event. Command and Navigation keys are Backspace, Delete, Tab, all Arrows, Home, End, etc.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/70335d3f4188
Set keyCode or charCode of keypress event whose value is zero to the other's non-zero value by default again unless dispatched on known broken web apps r=smaug

Comment 17

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/70335d3f4188

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

https://groups.google.com/forum/#!topic/mozilla.dev.platform/IWLLJmoGroA

Comment 19

[Yuri Khan]

Hello there,

I have noticed that in Firefox 65 Nightly I have trouble entering the U+002E FULL STOP character in the Confluence wiki at my job, only in certain circumstances:

1. Go to the end of any paragraph in a comment entry form or article editor.
2. Enter some text.
3. Press the full stop key.

Expected behavior: After step 3, the paragraph ends in a full stop character.

Observed behavior: In step 3, no character is inserted.

• The issue does not reproduce if not at end of paragraph.
• If I just position the insertion point at the end of paragraph and press “.”, it is inserted normally. It is only lost if I press it after typing some other text.
• Pasting a full stop character from clipboard works.

We have an outdated version of Confluence which uses an outdated version of TinyMCE. I do not observe the problem on the live demo on the TinyMCE site. I have not tested on the latest version of Confluence.

mozregression points here:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2f968d0631f513abd33a76f564a9c2b32377216c&tochange=70335d3f41881cd85b99a23342fc254b3783638f

What should I do? Can I add our Confluence domain to the black list locally?

Comment 20

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

What should I do? Can I add our Confluence domain to the black list locally?

If you want to use Nightly for your Confluence, yes, you need to add the domain into the blacklist. Although bug 1514940 should be fixed in next week.

Comment 21

[Timea Zsoldos [:zstimi/tzsoldos], Desktop QA]

I try to reproduced this bug, unfortunately without success. Masayuki could you provide me some steps ex. on Google Docs to reproduced this issue.

I observed that on Firefox nightly 65.0a1 (2018.10.29) the pref dom.keyboardevent.keypress.set_keycode_and_charcode_to_same_value = false, on Firefox 65.0 the pref value is false and on Firefox beta 66.0b3 the pref value is true, this is enough to mark this bug verified as fixed?

Note: In Fx 66.0b3 using the textbox from bug 1478102 you can type only number.

Comment 22

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

(In reply to Timea Zsoldos [:zstimi/tzsoldos], Desktop Release QA from comment #21)

I try to reproduced this bug, unfortunately without success. Masayuki could you provide me some steps ex. on Google Docs to reproduced this issue.

IIRC, we couldn't type some characters from 'a' to 'z' in Google Docs (at least in the word processor).

I observed that on Firefox nightly 65.0a1 (2018.10.29) the pref dom.keyboardevent.keypress.set_keycode_and_charcode_to_same_value = false, on Firefox 65.0 the pref value is false and on Firefox beta 66.0b3 the pref value is true, this is enough to mark this bug verified as fixed?

Note: In Fx 66.0b3 using the textbox from bug 1478102 you can type only number.

Shipping of this new behavior is put off to 66. See bug 1520756. Really sorry for making you confused.

Comment 23

[Timea Zsoldos [:zstimi/tzsoldos], Desktop QA]

Finally I reproduced this issue with this link: https://www.austroclass.com/BancoAustroWeb/login using Fx nightly 65.0a1 (2018.10.29) on Fx 65.0 (build ID = 20190124174741) still reproduced.
Verify on Fx 65.0b10 here this issue is fixed. What should I do next?

Comment 24

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

(In reply to Timea Zsoldos [:zstimi/tzsoldos], Desktop Release QA from comment #23)

Finally I reproduced this issue with this link: https://www.austroclass.com/BancoAustroWeb/login using Fx nightly 65.0a1 (2018.10.29) on Fx 65.0 (build ID = 20190124174741) still reproduced.

Yeah, should be so.

Verify on Fx 65.0b10 here this issue is fixed. What should I do next?

It should've been fixed on 66 and later. I.e., beta and Nightly. (Just this fix was put off from 65 to 66 and later.)

Comment 25

[Timea Zsoldos [:zstimi/tzsoldos], Desktop QA]

Are you intending to put this fix in Firefox RC 65.0?

Comment 26

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

(In reply to Timea Zsoldos [:zstimi/tzsoldos], Desktop Release QA from comment #25)

Are you intending to put this fix in Firefox RC 65.0?

No. I mean that the compat issue of the reported web app shouldn't be fixed in 65 (unless the web app fixed by their side).