[GLFW] Fix the bug that prevents any text on the site from being deleted #22879
Conversation
sbc100
changed the title
src/library_glfw.js
Outdated
| if (event.keyCode === 8 /* backspace */ || event.keyCode === 9 /* tab */) { | ||
| // Prevent default behavior for backspace and tab keys when the event target is not an input or textarea element. | ||
| // If prevented when input and textarea are prevented, no text in the site can be deleted | ||
| if ( event.target.localName !== "input" && event.target.localName !== "textarea" && |
src/library_glfw.js
Outdated
| @@ -419,7 +419,10 @@ var LibraryGLFW = { | |||
| // This logic comes directly from the sdl implementation. We cannot | |||
| // call preventDefault on all keydown events otherwise onKeyPress will | |||
| // not get called | |||
| if (event.keyCode === 8 /* backspace */ || event.keyCode === 9 /* tab */) { | |||
| // Prevent default behavior for backspace and tab keys when the event target is not an input or textarea element. | |||
| // If prevented when input and textarea are prevented, no text in the site can be deleted | |||
There was a problem hiding this comment.
How about Otherwise, no text in the site can be deleted.
Can you wrap this comment at 80 columns?
Should we make the same change to library_sdl.js perhaps?
src/library_glfw.js
Outdated
| if (event.keyCode === 8 /* backspace */ || event.keyCode === 9 /* tab */) { | ||
| // Prevent default behavior for backspace and tab keys when the event target is not an input or textarea element. | ||
| // If prevented when input and textarea are prevented, no text in the site can be deleted | ||
| if ( event.target.localName !== "input" && event.target.localName !== "textarea" && |
There was a problem hiding this comment.
Why use target.localName rather than, for example, target.tabName? I'm not sure what localName is so maybe you can help me out?
|
I tried to make the improvements you mentioned. I have not used tagName before, thank you for the advice, it seems to be a better choice. Also I added same things for sdl. @sbc100 |
Sorry I meant |
|
It looks like you somehow included copies of some other changes that already landed when you rebased/merged here. |
|
I wanted to remove old one for new 2 commit. But somehow i added unrelated commits. |
|
Is this related to #6143 ? I don't think we had a clear resolution there. |
Yes, I try to fix that problem. |
|
@uysalibov I understand, but see @juj's point in that older discussion - there are tradeoffs here, and it's not obvious that flipping it the other way is better. And it would be disruptive to existing users. I don't have a strong preference myself, except that if we change a long-standing tradeoff in a disruptive way then we should have a very strong reason. |
|
@kripken I can't find a way to remove these related preventation in the structure in the old version. Assuming that the whole page is canvas doesn't seem very correct to me today. It's easier to block these keys (backspace and tab) in the project. On the contrary, we cannot find a solution to this situation since 2018. |
I agree it might not be the best default. It does help porting fullscreen games and similar applications, which historically has been popular with Emscripten. I think that's why we ended up here. I agree we should think about how to improve things. Can you explain how the |
|
Imagine a page with canvas and input. Normally |
|
@uysalibov I understand that, but I am asking specifically about Another option might be to check if the event was sent to the canvas, and swallowed if so. |
No, those are the names of the HTML tags that accept text as input (Here we are looking at the
|
|
Oh, thanks, I was confusing Id with Tag I guess. In that case this does sound pretty safe, sgtm. I do think we should add testing for it. Relevant tests is https://github.com/emscripten-core/emscripten/blob/main/test/browser/test_glfw_events.c and you can run it with |
I think it's not an option. Because the key event does not always come from the canvas element. Most of the time it comes from the |
If glfw is initizalized, it prevents the deletion of text in the input and textarea elements on the site. If this is not filtered like this, no form on the site works as desired.
Related issue: #22866