gh-obsproject/obs-browser

Watch

Fork 0

KeyboardEvent properties don't match real browsers #319

New issue

Open

opened 2021-10-06 03:35:20 -05:00 by Amphitryon0 · 7 comments

Amphitryon0 commented

2021-10-06 03:35:20 -05:00

(Migrated from github.com)

Operating System Info

Windows 10

Other OS

No response

OBS Studio Version

27.2.4

OBS Studio Version (Other)

No response

OBS Studio Log URL

https://obsproject.com/logs/1RjIPQfX0BqFKJ98

OBS Studio Crash Log URL

No response

Expected Behavior

The KeyboardEvent generated should be similar to that originating in a regular browser. For example, using a standard US layout, typing a colon with the right shift key should generate two events with (among others) the following properties:

.code	.key	.location
"ShiftRight"	"Shift"	2
"Semicolon"	":"	0

Current Behavior

Using the same example of typing a colon, I see the following properties:

.code	.key	.location
""	"Shift"	0
""	":"	0

From this and other tests, it seems that code is always blank, and location is always 0.

Steps to Reproduce

Create a browser source with the URL set to https://domeventviewer.com/key-event-viewer.html. Leave the other settings unchanged.
Interact with the source and press a key.
Observe incorrect properties.

Anything else we should know?

I saw that there have been similar issues closed, but I'm not sure if they were considered fixed or just as close as we could get. If it's the latter case, I'm sorry for being yet another person to bring this up. The webpage I'm actually using can be modified to use OBS's key values when it detects that it's running in OBS, but then it's still locked to one keyboard layout.

### Operating System Info Windows 10 ### Other OS _No response_ ### OBS Studio Version 27.2.4 ### OBS Studio Version (Other) _No response_ ### OBS Studio Log URL https://obsproject.com/logs/1RjIPQfX0BqFKJ98 ### OBS Studio Crash Log URL _No response_ ### Expected Behavior The KeyboardEvent generated should be similar to that originating in a regular browser. For example, using a standard US layout, typing a colon with the right shift key should generate two events with (among others) the following properties: | .code | .key | .location | | :----------- | :------ | :-------- | | "ShiftRight" | "Shift" | 2 | | "Semicolon" | ":" | 0 | ### Current Behavior Using the same example of typing a colon, I see the following properties: | .code | .key | .location | | :---- | :------ | :-------- | | "" | "Shift" | 0 | | "" | ":" | 0 | From this and other tests, it seems that code is always blank, and location is always 0. ### Steps to Reproduce 1. Create a browser source with the URL set to `https://domeventviewer.com/key-event-viewer.html`. Leave the other settings unchanged. 2. Interact with the source and press a key. 3. Observe incorrect properties. ### Anything else we should know? I saw that there have been similar issues closed, but I'm not sure if they were considered fixed or just as close as we could get. If it's the latter case, I'm sorry for being yet another person to bring this up. The webpage I'm actually using can be modified to use OBS's key values when it detects that it's running in OBS, but then it's still locked to one keyboard layout.

ElectronicWar commented

2021-10-06 03:41:56 -05:00

(Migrated from github.com)

We are more or less at the mercy of CEF here and how it handles these things. Please mind that on Windows, our CEF is quite old (equivalent of Chrome 75) and this alone might make the difference.

You can track progress in updating to a newer CEF release here: https://github.com/obsproject/obs-studio/discussions/3853

We are more or less at the mercy of CEF here and how it handles these things. Please mind that on Windows, our CEF is quite old (equivalent of Chrome 75) and this alone might make the difference. You can track progress in updating to a newer CEF release here: https://github.com/obsproject/obs-studio/discussions/3853

WizardCM commented

2021-10-06 03:45:16 -05:00

(Migrated from github.com)

This is something I've been trying my best to try and fix over time. github.com/obsproject/obs-browser@a14ed2fe attempts to get it relatively functional on macOS, github.com/obsproject/obs-browser@ae25c36a attempted to fix it on Linux, and I've always tested it on Windows.

I also use keycode.info as a smoke test, but I can confirm modifiers are a bit of a nightmare. I admit that I hadn't been testing colon vs semicolon.

It's definitely an area I want to improve further - the challenge is that we go through 3 layers of conversion: first Qt reads it, it gets converted into an obs_key_t, and then we convert that to something CEF approves of.

Additionally, the OBS Interact window doesn't handle held keys or related events - that's the same reason drag & drop cursor events don't work properly.

I'll continue experimenting with this when I have the motivation. Honestly this particular OBS API is a bit of a nightmare to work with.

This is something I've been trying my best to try and fix over time. https://github.com/obsproject/obs-browser/commit/a14ed2fe attempts to get it relatively functional on macOS, https://github.com/obsproject/obs-browser/commit/ae25c36a attempted to fix it on Linux, and I've always tested it on Windows. I also use keycode.info as a smoke test, but I can confirm modifiers are a bit of a nightmare. I admit that I hadn't been testing colon vs semicolon. It's definitely an area I want to improve further - the challenge is that we go through 3 layers of conversion: first Qt reads it, it gets converted into an `obs_key_t`, and then we convert that to something CEF approves of. Additionally, the OBS Interact window doesn't handle held keys or related events - that's the same reason drag & drop cursor events don't work properly. I'll continue experimenting with this when I have the motivation. Honestly this particular OBS API is a bit of a nightmare to work with.

WizardCM commented

2021-10-06 04:02:14 -05:00

(Migrated from github.com)

Edit: Oh god did my recent changes break #236 again? I hope not.

WizardCM commented

2021-10-06 05:17:02 -05:00

(Migrated from github.com)

OK, after further testing, recent code did not break this. What I've actually learned is that the event->text from OBS to CEF is correct, but by the time it reaches the webpage it's wrong. I'm not quite sure why.

Additionally, the good news is that the "modifiers" match on OBS and CEF, so that particular aspect we don't need to worry about.

Top: Browser Dock
Bottom: Browser Source

OK, after further testing, recent code did not break this. What I've actually learned is that the `event->text` from OBS to CEF is correct, but by the time it reaches the webpage it's wrong. I'm not quite sure why. Additionally, the good news is that the "modifiers" match on OBS and CEF, so that particular aspect we don't need to worry about. Top: Browser Dock Bottom: Browser Source ![image](https://user-images.githubusercontent.com/941350/136187001-339250d9-0239-4995-84f2-d5afd16c4bcd.png)

Amphitryon0 commented

2022-06-16 21:46:01 -05:00

(Migrated from github.com)

I updated the report to indicate what occurs on 27.2.4 (which is almost the same), and I updated the steps to reproduce since keycode.info is no longer accurate. One other thing I noticed (though you probably were aware of it) is that interacting with a browser source through remote debugging gives mostly correct property values.

Amphitryon0 commented

2022-06-16 22:30:28 -05:00

(Migrated from github.com)

Also, the modifiers do not match exactly. The modifier states for Shift, Ctrl, and Alt (and their specific properties) are false on keydown and true on keyup of their respective keys. The wording of the spec isn't super clear about that imo, but its examples show them as true on keydown and false on keyup, which is also what happens in remote debugging. The Meta modifier and its property, as well as Caps Lock, Scroll Lock, and Num Lock, are always false. (Meta and its property can be true for events from remote debugging, but the other modifiers will not.)

pkviet commented

2024-03-29 05:43:14 -05:00

(Migrated from github.com)

This seems related to this CEF bug:
https://github.com/chromiumembedded/cef/issues/2597

This seems related to this CEF bug: https://github.com/chromiumembedded/cef/issues/2597

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-obsproject/obs-browser#319

No description provided.

Rows
Columns