Closed Bug 1502795 Opened 6 years ago Closed 6 years ago

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

Categories

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

Product:
Core
Component:
DOM: Events
Type:
enhancement

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla65
Tracking Flags:
Tracking Status
firefox65 --- wontfix
firefox66 --- verified

People

(Reporter: masayuki, Assigned: masayuki)

References

(Regressed 1 open bug)

Details

Attachments

(1 file)

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
(deleted), text/x-phabricator-request
Details
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.
Priority: -- → P2
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.)
Flags: needinfo?(overholt)
why did you mention www.rememberthemilk.com, was that one of the affected sites?
(http://rememberthemilk.com, I thought adding www. here would act as clickable link)
No longer blocks: 1478102
Blocks: 1478102
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!
(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.
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.
(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.
(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.
Flags: needinfo?(overholt)
Do you mean key pressed/released by "keydown/keyup"?
(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.
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.
(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.
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.
Pushed by masayuki@d-toybox.com: 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
https://hg.mozilla.org/mozilla-central/rev/70335d3f4188
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox65: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
Flags: qe-verify+

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?

Flags: needinfo?(masayuki)

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.

Flags: needinfo?(masayuki)

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.

Flags: needinfo?(masayuki)

(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.

Flags: needinfo?(masayuki)

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?

Flags: needinfo?(masayuki)

(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.)

Flags: needinfo?(masayuki)

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

Flags: needinfo?(masayuki)

(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).

Flags: needinfo?(masayuki)
Status: RESOLVED → VERIFIED
Blocks: 1526984
Depends on: 1536453
Depends on: 1538126
Depends on: 1538317
Depends on: 1538652
Depends on: 1538651
Depends on: 1539087
Depends on: 1538970
Depends on: 1540158
No longer depends on: 1538970
Regressions: 1538970
No longer depends on: 1538651
Regressions: 1538651
No longer depends on: 1538652
Regressions: 1538652
No longer depends on: 1538317
Regressions: 1538317
Depends on: 1543507
Regressions: 1543507
Regressions: 1546030
No longer depends on: 1536453
Regressions: 1536453
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: