User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

Create a new document with Google Drive, and try to type "À" (uppercase A with grave accent: A + `) in the body of the document.

Actual results:

Writes nothing.

Expected results:

Appear the typed character.

It stopped working a few versions ago.
And seems to happen only with Windows systems (Windows 7 and 10 tested). On macOS and Linux worked fine.

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Hi,

I have managed to reproduce this issue on latest FF release (66.0.5) and latest Nightly build 68.0a1 (2019-05-19) using Windows 10.
Note that in older versions the issue is not reproducible.

I'm going to set a component so developers can take a look at it. If this is not the right component, please feel free to move it to a more appropriate one.

Thank you for the report.

Hi Mirko,
This sounds a recent regression that affects a popular web services, a higher priority. Could you try to find a regression and take a look at this?

Indeed, seems to be a Windows specific problem. Typing "È Ì Ò Ù" still works. In <textarea>'s like the one where this comment is written in, it still works.

Regression found:

2019-05-27T12:14:35: DEBUG : Starting merge handling...
2019-05-27T12:14:35: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=ce0cebad842b1fc3c14b552dccaa59dc9ec8dd09&full=1
2019-05-27T12:14:36: DEBUG : Found commit message:
Bug 1510081 - Remove docs.google.com from "dom.keyboardevent.keypress.hack.use_legacy_keycode_and_charcode" r=smaug

It seems that Google Docs have already been fixed their bugs of mirroring
keyCode and charCode values of our keypress events.  Therefore, we should
remove docs.google.com from the blacklist and collect new feedback from
Nightly testers.

Differential Revision: https://phabricator.services.mozilla.com/D13035

2019-05-27T12:14:36: DEBUG : Did not find a branch, checking all integration branches
2019-05-27T12:14:36: INFO : The bisection is done.
2019-05-27T12:14:36: INFO : Stopped```

Masayuki: rings a bell ?
Thanks

Okay, so, it must be a bug of Google Docs. Mike?

Hi, this doesn't reproduce for me today in Google Docs on Mac. I'm able to type À. Is your locale set to something other than en-US perhaps?

(In reply to Mike Taylor [:miketaylr] from comment #8)

Hi, this doesn't reproduce for me today in Google Docs on Mac. I'm able to type À. Is your locale set to something other than en-US perhaps?

I've tested it with Spanish and Catalan localized Windows, with the most recent stable version of Firefox, and it -still- fails. Same systems with Chrome and Edge work fine. Previous versions worked fine.
Spanish and Catalan localized macOS (El Capitan and above) work fine.
English localized Debian-derivate Linux distribution works fine too.

Thanks for the info, that's very helpful.

I did a regression range on Windows 10 x64 and here is the regression window:
Last good revision: cda49d66b3ccef746f0f077b80173cf0ae3a2899
First bad revision: ce0cebad842b1fc3c14b552dccaa59dc9ec8dd09
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cda49d66b3ccef746f0f077b80173cf0ae3a2899&tochange=ce0cebad842b1fc3c14b552dccaa59dc9ec8dd09

This is also affecting French users which is one of our top 5 locales (and like in Catalan, starting a sentence with À is not uncommon in French). I think that a P1 regression potentially affecting a lot of our users should not remain unassigned.

I've contacted Google on our partner list, will update here.

Google is investigating, but have asked that we add GDocs back to the legacy behavior whitelist.

Can we get Google Docs added back to the legacy keycode blacklist while
we're getting this figured out?

I'm not sure if there will be a ridealong opportunity for a 67 dot release if we do land a patch, but nominating for tracking to get on the radar.

Google is aware of the reported issue, but have asked us to opt back
into legacy behavior until they can investigate and deploy a fix.

Moving product since Google will have to fix this for us.

Note: no need to switch locales to reproduce. Typing Alt+0192 on Windows will result in expected results in Chrome and actual results in Firefox.

(self ni? to request beta uplift once this lands and is verified in nightly)

https://hg.mozilla.org/mozilla-central/rev/1a77272644bc

I've confirmed the fix in Nightly on Windows, but I just received the following update from google:

We have a special case for keyCode 192, put in place along time ago to fix "stray kepress events" with Firefox 3 on Windows. Kirti confirmed this special case isn't needed anymore with Firefox 64, presumably hasn't been for a long time. We'll remove this code on our end, and try and have this out to production users early next week if everything goes well.

It sounds like that's probably faster than a dot release, so I'd like to keep this patch in Nightly as a workaround until Docs ships their fix to all users.

Thanks for reporting this issue tecnic.ara.

Tracking for all channels though it sounds like we shouldn't need to do anything else on our end other than reverting the Nightly patch eventually.

Hi Mike, please request uplift for Beta68 if you think it's worth shipping this fix in 68.

Thanks - I've just tested, and the fix hasn't been deployed yet. I'll try again tomorrow and we can make some decisions then (and re-ping Google).

I've just tested it with version 67.0.1 (64 bits) on a Windows 10, and it's working as expected.

Thanks! I also just tested and it's working in 67 and 68 on Win10, and Google wrote us to say the same.

The backout was merged to m-c also.
https://hg.mozilla.org/mozilla-central/rev/fec58dda0658

I think we can resolve this as wontfix now that Google has rolled out the fix on their end?

Sure, that works. Typically in the "Web Compatibility" product we resolve things as fixed when the site is working again (generally when the site fixes itself). But I don't feel strongly, so let's WONTFIX here.

Fixed is fine with me here if that's SOP for this component :)