keypress events are not getting spoofed

While writing the Keyboard fingerprinting section in our design document I researched a bit and found this excellent keyboard properties test: https://w3c.github.io/uievents/tools/key-event-viewer.html

I played a bit with it and to my surprise it showed at least the keypress event not being properly spoofed. The result for pressing ? on a german keyboard with german keyboard layout are attached.

added component::applications/tor browser owner::tbb-team priority::high resolution::not a bug severity::major status::closed tbb-fingerprinting type::defect labels

Trac:

A noteworthy thing on the screenshot is the ß character as that is the key I actually pressed. Two other things I am wondering:

1. Did that regress? (It seems so)
2. We have tests for our keyboard spoofing. Do they need improvement for not catching this?

Trac:
Owner: N/A to tbb-team
Priority: Medium to High
Keywords: N/A deleted, tbb-fingerprinting added
Cc: N/A to arthuredelstein
Severity: Normal to Major
Component: - Select a component to Applications/Tor Browser

It's not a regression, it's just an unimplemented feature. Here's the ticket: #16678 (moved).

But it's a good reminder to work on this.

Trac:
Status: new to closed
Resolution: N/A to duplicate

Replying to arthuredelstein:

It's not a regression, it's just an unimplemented feature. Here's the ticket: #16678 (moved).

Wait, wait, this is not about the ß key. As the bug title says it is about the keypress event. If you look again at the screenshot you'll see that there is no ß in the keypress row. But rather, there are charCode and which values that should be 191 instead of 63 as I am pressing the ? key. I basically tested with the same key as back in #15646 (moved). If you look at comment:13:ticket:15646 I got the same results for that event. It bothers me that I don't know anymore why I said "It looks better now" in comment:23:ticket:15646 because testing a bunch of older versions shows the same behavior. Thus, it seems we never fixed that part of my review feedback for some reason.

Regarding the ß result in the screenshot. Even though it is shown that the ? key is pressed the ß shows up if one releases the Shift key a bit earlier than the ? key. So, this part is indeed no regression rather a testing error. I got just confused that the ß showed up while the test said I pressed the ? key.

Trac:
Status: closed to reopened
Resolution: duplicate to N/A

Replying to gk:

Replying to arthuredelstein:

It's not a regression, it's just an unimplemented feature. Here's the ticket: #16678 (moved).

Wait, wait, this is not about the ß key.

Oops, sorry! :) I misunderstood. In comment:1 you say "A noteworthy thing on the screenshot is the ß character as that is the key I actually pressed." So I assumed the ? in the Description was just the ß failing to render in trac.

I will investigate this further. What OS did you observe this on?

Replying to arthuredelstein:

Replying to gk:

Replying to arthuredelstein:

It's not a regression, it's just an unimplemented feature. Here's the ticket: #16678 (moved).

Wait, wait, this is not about the ß key.

Oops, sorry! :) I misunderstood. In comment:1 you say "A noteworthy thing on the screenshot is the ß character as that is the key I actually pressed." So I assumed the ? in the Description was just the ß failing to render in trac.

No worries. :)

I will investigate this further. What OS did you observe this on?

Both on Windows and Linux with german keyboard and german keyboard layout. I can test on other setups later next week if that's necessary.

I am getting the same result with a german keyboard and an en-US layout. Thus, it seems to me the keypress event leaks the fact that I have a german keyboard regardless of the layout ("layout" means here and in my comments above "funtional layout" while "german keyboard" means "german visual layout").

Trac:

Trac:

I added z and Z test cases as well.

Okay, this is not a bug. It turns out I mixed up charCode and keyCode values. While we spoof the latter the former are merely ASCII values of the key that got pressed. By coincidence both give back 63 for ? on a with a german layout without spoofing. Our patch fixes that for the keyCode case leacing the charCode case untouched as it does not vary with a different keyboard layout.

Trac:
Status: reopened to closed
Resolution: N/A to not a bug

closed

mentioned in issue #21426 (moved)

moved to tpo/applications/tor-browser#21390 (closed)

mentioned in issue tpo/applications/tor-browser#21426