Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Browser extensions "stealing" input from html export #62606

Closed
RPicster opened this issue Jul 1, 2022 · 7 comments
Closed

Browser extensions "stealing" input from html export #62606

RPicster opened this issue Jul 1, 2022 · 7 comments
Assignees
@Faless
Labels
archived discussion platform:web topic:input topic:porting

Comments

@RPicster
Copy link
Contributor

RPicster commented Jul 1, 2022

Godot version

3.5RC4

System information

Windows 10

Issue description

When using browser extensions that use shortcuts, e.g. for navigation, those shortcuts "steal" the input of html5 exported Godot projects.

Steps to reproduce

  • Install an extension that uses keyboard shortcuts for input. (e.g. Vimium C on Chrome)
  • Browse to https://editor.godotengine.org/
  • Create a new project
  • As the name enter Hello
  • Vimium will capture "H" (Shift + H) as the shortcut to go back in browser history.

Minimal reproduction project

Not neccessary, see above.
@RPicster
Copy link
Contributor Author

RPicster commented Jul 1, 2022 •
edited
Loading

Adding to the "bug report" - Yes I am fully aware that this is in part a problem of using said extension(s).
But, I am working on a project where keyboard input + html5 is mandatory and it's not just Vimium. Vimium is a good example as it captures so many different key.

I asked in the Vimium github issues for solutions - it's the "desired" behaviour and in this case I was suggested to turn off Vimium. But on other extensions (e.g. Key Jump) it's not just easily deactivable.

I tested a local workaround that seemed to work:
replacing <body> with <body contenteditable=true> - This seemed to work and stopped extensions from capturing those inputs (as it is now treated like an input field).

The question now would be if this behaviour could be implemented as the default behaviour in the html5 export.
To make this "hack" work and to result in a "normal" behaviour, it was also neccessary to add the cursor style to the body tag:
<body contenteditable=true style="cursor: default">
And also change the cursor style that is used by Godot from auto (Browser decides which cursor to display) to default (Use the default cursor).

I opened two PRs for master and 3.x:
#62608
#62607

@RPicster RPicster mentioned this issue Jul 1, 2022
Merged
@Faless
Copy link
Collaborator

Faless commented Jul 2, 2022

Fixed via #62607

@Faless Faless closed this as completed Jul 2, 2022
@Faless
Copy link
Collaborator

Faless commented Jul 2, 2022

The question now would be if this behaviour could be implemented as the default behaviour in the html5 export.

Setting contenteditable=true is not an option, since that has it's own specific meaning, which we don't want, and can easily break on different browsers/platforms:
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/contenteditable

If you need to customize the HTML to account for your specific setup, you can set a custom HTML page on export

@RPicster RPicster reopened this Jul 2, 2022
@RPicster
Copy link
Contributor Author

RPicster commented Jul 2, 2022

The PRs that I mentioned do not fix this problem, they fix a general problem that leads to a wrong cursor under certain circumstances.

I know that I can setup a custom html, but my specific setup is not the problem here.

Like I said, even the original web editor of Godot suffers from this problem.

Is there another solution to this that you know of?

@Faless
Copy link
Collaborator

Faless commented Jul 2, 2022 •
edited
Loading

The PRs that I mentioned do not fix this problem, they fix a general problem that leads to a wrong cursor under certain circumstances.

The PR allows you to fix it via a custom HTML page (without having the wrong cursor).

Is there another solution to this that you know of?

You should ask the extensions developers, it's clearly them who steal the input by modifying the HTML content. Nothing we can do about that as far as I know (EDIT: I don't know how their extension works, so there might be something we could do, but I have no clue).

And given they told you to disable the extension, I guess there is no solution beside not using an extension that breaks web pages.

@Faless
Copy link
Collaborator

Faless commented Jul 2, 2022

Did you try opening an issue on their github? https://github.com/KennethSundqvist/key-jump-browser-extension

@Faless
Copy link
Collaborator

Faless commented Jul 2, 2022

They seem to use capture on purpose, i.e. they actively want to steal events at the window level (as soon as they arrive):
https://github.com/KennethSundqvist/key-jump-browser-extension/blob/master/src/content.js#L44-L45

With this in mind (see event flow) I'm pretty confident there is nothing we can do about it.

They should just fix their extension.

@Faless Faless closed this as not planned Won't fix, can't repro, duplicate, stale Jul 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Faless Faless

Labels
archived discussion platform:web topic:input topic:porting
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@Faless @akien-mga @RPicster