User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0 Build ID: 20180511220149 Steps to reproduce: 1. Opened a RAP based application, like: http://192.168.56.1:8080/rap 2. clicked on the tree widget 3. tried to navigate through using the arrow keys: Actual results: arrow keys did not work Expected results: navigation should be possible as it was with firefox before ~2018.04 and as it is with all other browsers

screencast illustrating the issue: https://youtu.be/WPtaAsH6Ogw 16:19.88 INFO: Narrowed inbound regression window from [1e6febc9, 2ab582ba] (3 builds) to [d10dc4dc, 2ab582ba] (2 builds) (~1 steps left) 16:19.88 INFO: No more inbound revisions, bisection finished. 16:19.88 INFO: Last good revision: d10dc4dc4162b15320bf468adaf5cf0859666c23 16:19.88 INFO: First bad revision: 2ab582bacc98fecfc3cc52b3f275a23ff40a683f 16:19.88 INFO: Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d10dc4dc4162b15320bf468adaf5cf0859666c23&tochange=2ab582bacc98fecfc3cc52b3f275a23ff40a683f

Yeah, RAP does hack only for Gecko even though this must not be unnecessary since they can handle them at "keydown" with Event.preventDefault(). If they need to check if keypress event is redundant on Gecko (i.e., it'll be stopped in the future release), they can check it with: function isRedundantKeyPress(aEvent) { if (aEvent.type != "keypress") { return false; } if (aEvent.key === "Enter") { // Only Enter, Shift + Enter, Ctrl + Enter causes keypress event on newer Firefox. if (aEvent.metaKey || aEvent.altKey) { return true; } return (aEvent.shiftKey && aEvent.ctrlKey); } // If any character isn't produced, the key combination won't cause keypress event on newer Firefox. if (!aEvent.charCode) { return true; } // If a character is produced, ctrlKey, altKey and metaKey are always false of keypress event on Firefox. return aEvent.ctrlKey || aEvent.altKey || aEvent.metaKey; } If this returns true for a keypress event, the event should be ignored and any non-printable key operation should be handled at keydown event.

I will file a bug-report against RAP - however what is the timeframe this Gecko change is expected to land? RAP is quite widely used in corporate-internal web apps.

(In reply to Clemens Eisserer from comment #3) > I will file a bug-report against RAP - however what is the timeframe this > Gecko change is expected to land? > RAP is quite widely used in corporate-internal web apps. We don't have fixed schedule yet. Depending on how many and how important web apps are broken. For example, currently, most google's applications are broken and they're working on fix right now. On the other hand, this change is important for us. Therefore, even if some web apps using RAP is broken when we release the new behavior, we'd release perhaps.

Adam, could you investigate how we can get in touch with this project? Comment #3 mentions a bug report, but it would be good to reach out as well, I think.

Clemens was so kind to open a bug report against our Eclipse RAP project: 534628: Keyboard navigation broken in tree widget with Firefox Nightly/Beta releases https://bugs.eclipse.org/bugs/show_bug.cgi?id=534628 Thanks for bringing this to our attention! We are now aware of it, and will be watching this bug. On our side we'd need the final Firefox version number in order to limit the fix to it, and to avoid compatibility issues or regressions in older versions. As soon as the Firefox schedule is finalized, we'd be thankful to get this information. At the moment we are in the release candidate phase of RAP 3.5. When this change is included in Firefox, we could integrate the fix in an early nightly RAP build towards 3.6M1, or whenever appropriate.

(In reply to Markus from comment #6) > On our side we'd need the final Firefox version number in order to limit the > fix to it, and to avoid compatibility issues or regressions in older > versions. As soon as the Firefox schedule is finalized, we'd be thankful to > get this information. No, until most existing web apps fix their behavior, we cannot release the new behavior at least for now because if some web apps will be broken by the new behavior, users using such web apps may decide to switch their default browser from Firefox. As I explained at comment 2, web apps should ignore unnecessary keypress events and handle keydown events as same as running on the other browsers. # And I found a bug at comment 2. The last return statement should ignore altKey value only on macOS since for example, option + KeyA may cause inputting a Unicode character. When an editor (<input>, <textarea>, contenteditable, etc) has focus, Gecko unset altKey value but not so when no editor has focus.

Mantaroh has created a patch for this and, with Ivan's help, it seems to be all but ready to merge. It does appear to have missed the 3.6 release, however.

Yes, we have a patch ready to be merged. I have couple of questions: 1. Is this major Firefox change announced and documented somewhere in a release notes or other place (blog post)? We need this information in order to announce it in our RAP home page. 2. To make the change safe and still compatible with the older Firefox version we have a version switch in the code. What is the planned Firefox release version of this change - Firefox 64 (release in December)? If this is the case, it will be just in time for RAP 3.7 release (December 19th). 3. Do you have any list of users for product upgrade communication, where you can announce that RAP 3.7 will be compatible with this Firefox change?

(In reply to Ivan Furnadjiev from comment #9) > Yes, we have a patch ready to be merged. I have couple of questions: > 1. Is this major Firefox change announced and documented somewhere in a > release notes or other place (blog post)? We need this information in order > to announce it in our RAP home page. Although I don't know there is "official" one since we still don't have fixed schedule of its release. But here is the document: https://www.fxsitecompat.com/en-CA/docs/2018/non-printable-keys-will-soon-stop-firing-keypress-event/ > 2. To make the change safe and still compatible with the older Firefox > version we have a version switch in the code. What is the planned Firefox > release version of this change - Firefox 64 (release in December)? If this > is the case, it will be just in time for RAP 3.7 release (December 19th). Not yet fixed since medium.com is still broken, and we're waiting their fix. > 3. Do you have any list of users for product upgrade communication, where > you can announce that RAP 3.7 will be compatible with this Firefox change? I don't know, but as far as I know, there is no user-list of specific service/framework.

(In reply to Ivan Furnadjiev from comment #9) > 3. Do you have any list of users for product upgrade communication, where > you can announce that RAP 3.7 will be compatible with this Firefox change? Maybe we could make an annoucement on our enterprise mailing list? https://mail.mozilla.org/listinfo/enterprise (probably not huge circulation, but it's better than nothing...) Adam, could you help with that?

Yep, talked to mkaply. I'll draft up an email and he'll post it to the list. Leaving NI for now.

Is the release date of this change fixed now - Firefox 64 (release in December)?

(In reply to Ivan Furnadjiev from comment #13) > Is the release date of this change fixed now - Firefox 64 (release in > December)? It's not fixed. Unfortunately there are a number of interrelated changes that might need to be shipped together. As I understand it, Firefox 65 (currently scheduled for 2019-01-29) is the earliest we're likely to ship the keypress changes.