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.

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

Handle KeyboardEvent without virtual key code #15800

Closed
wants to merge 5 commits into from

Conversation

@charlesvdv
Copy link
Contributor

charlesvdv commented Mar 2, 2017

This PR allows to properly handling KeyboardEvent without a virtual key code.

These PR is not completed yet but I prefer start a discussion to see if my approach is correct to you. (For exemple I have to remove the Result over here).


  • ./mach build -d does not report any errors
  • ./mach test-tidy does not report any errors
  • These changes fix #15240 (github issue number if applicable).
  • Theses changes should fix #12616
  • There are tests for these changes OR
  • These changes do not require tests because _____

This change is Reviewable

@highfive
Copy link

highfive commented Mar 2, 2017

Heads up! This PR modifies the following files:

  • @fitzgen: components/script/dom/keyboardevent.rs
  • @KiChjang: components/script/dom/keyboardevent.rs
@highfive
Copy link

highfive commented Mar 2, 2017

warning Warning warning

  • These commits modify script code, but no tests are modified. Please consider adding a test!
Some(VirtualKeyCode::LAlt) => self.toggle_modifier(LEFT_ALT),
Some(VirtualKeyCode::RAlt) => self.toggle_modifier(RIGHT_ALT),
Some(VirtualKeyCode::LWin) => self.toggle_modifier(LEFT_SUPER),
Some(VirtualKeyCode::RWin) => self.toggle_modifier(RIGHT_SUPER),

This comment has been minimized.

Copy link
@KiChjang

KiChjang Mar 2, 2017

Member

Why is this an improvement?

This comment has been minimized.

Copy link
@charlesvdv

charlesvdv Mar 2, 2017

Author Contributor

This is the improvements because now we are handling correctly the case where virtual key code is None.

@@ -345,16 +345,16 @@ impl Window {
self.pending_key_event_char.set(Some(ch));
}
}
Event::KeyboardInput(element_state, scan_code, Some(virtual_key_code)) => {

This comment has been minimized.

Copy link
@KiChjang

KiChjang Mar 2, 2017

Member

Removing the match arm you linked should just be fine, why did you need to remove this Some()?

This comment has been minimized.

Copy link
@KiChjang

KiChjang Mar 2, 2017

Member

Oh I see, looks like you're rolling in functionality for handling Some and None into the same match arm. Would it not be ok to just make a separate match arm instead specifically for the None case?

This comment has been minimized.

Copy link
@charlesvdv

charlesvdv Mar 2, 2017

Author Contributor

Because before we were just handling the case with Some(virtual_key) but now we handle the case None (which doesn't change much the code so I put both on the same case).

This comment has been minimized.

Copy link
@KiChjang

KiChjang Mar 2, 2017

Member

I'm actually more of the opinion that we should split this up into different match arms. The common code between the two match arms should just be refactored into a separate function, since this arm is already pretty big as it is. What do you think?

This comment has been minimized.

Copy link
@charlesvdv

charlesvdv Mar 2, 2017

Author Contributor

I'm totally ok with that!

Event::KeyboardInput(_, _, None) => {
debug!("Keyboard input without virtual key.");
let key = match virtual_key_code {
Some(v) => Window::glutin_key_to_script_key(v).unwrap(),

This comment has been minimized.

Copy link
@KiChjang

KiChjang Mar 2, 2017

Member

Why is it OK to assume the unwrap wouldn't panic?

This comment has been minimized.

Copy link
@charlesvdv

charlesvdv Mar 2, 2017

Author Contributor

Because I will remove the Result from here but before doing so I prefer to see if you are ok with the changes 😄

This comment has been minimized.

Copy link
@KiChjang

KiChjang Mar 2, 2017

Member

Can't seem to follow the link you posted.

This comment has been minimized.

Copy link
@charlesvdv

charlesvdv Mar 2, 2017

Author Contributor
@KiChjang
Copy link
Member

KiChjang commented Mar 3, 2017

Changes look good to me, but I see that @jdm has raised some questions in the relevant issue. Handing this over to him for approval.
r? @jdm

@highfive highfive assigned jdm and unassigned KiChjang Mar 3, 2017
@jdm
Copy link
Member

jdm commented Mar 4, 2017

I'm not available for reviewing code right now, so I'm going to hand this off to @Ms2ger.
r? @Ms2ger

@highfive highfive assigned Ms2ger and unassigned jdm Mar 4, 2017
Copy link
Contributor

Ms2ger left a comment

I found it pretty hard to review, so I tried to split up your the refactoring from the actual changes: https://github.com/servo/servo/tree/keyboard-virtual.

Would you mind pushing that branch to your PR? That should help to evaluate it.

fn get_keyboard_input_char(&self, element_state: ElementState, scan_code: ScanCode) -> Option<char> {
match element_state {
ElementState::Pressed => {
// Retrieve any previosly stored ReceivedCharacter value.

This comment has been minimized.

Copy link
@Ms2ger

Ms2ger Mar 7, 2017

Contributor

"previously"

// Store the association between the scan code and the actual
// character value, if there is one.
let ch = self.pending_key_event_char
.get();

This comment has been minimized.

Copy link
@Ms2ger

Ms2ger Mar 7, 2017

Contributor

Can go on the previous line.

@charlesvdv charlesvdv force-pushed the charlesvdv:fix-keyboard branch from fb6d5d5 to 29ac79e Mar 8, 2017
@nox nox assigned nox and unassigned Ms2ger Mar 28, 2017
@nox
Copy link
Member

nox commented Apr 11, 2017

That changes from your last fixup commit needs to be properly squashed into the commits where they belong.

@nox
Copy link
Member

nox commented Apr 11, 2017

You don't need Key::Unidentified. Instead keep returning Result<Key, ()>, and use an Option<Key> with None where you used Key::Unidentified.

@bors-servo
Copy link
Contributor

bors-servo commented Apr 12, 2017

The latest upstream changes (presumably #16198) made this pull request unmergeable. Please resolve the merge conflicts.

@nox
Copy link
Member

nox commented Oct 9, 2017

@jonathandturner Think you could take a look at this? It became hard to rebase thanks to #16198.

@jonathandturner
Copy link

jonathandturner commented Oct 9, 2017

@nox - apologies. Wish I could help, though unfortunately too busy/out-of-the-loop to help fix.

@dralley
Copy link
Contributor

dralley commented Apr 20, 2020

I think this PR (as well as possibly the mentioned issue) are obsolete, it seems like Servo's keyboard event handling was made more spec-compliant by 0ccaa7e#diff-8dc9268416cd4f037d50206e76c73cf9

The linked issue also talks about Glutin limitations, I'm not sure if that is still relevant anymore either.

@jdm
Copy link
Member

jdm commented Apr 20, 2020

It certainly could still be relevant, since glutin just exported a bunch of input-related types and APIs from winit. We still rely on winit, so we probably still have the same input-related problems. However, this PR is not receiving any attention so I'm going to go ahead and close it.

@jdm jdm closed this Apr 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

10 participants
You can’t perform that action at this time.