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

Ignore navigation input if key state is Released #20628

Closed
wants to merge 1 commit into from

Conversation

@piotr-szpetkowski
Copy link
Contributor

piotr-szpetkowski commented Apr 12, 2018

Hi. As my first PR in Servo and also my first commit in any Rust project I've fixed issue with Navigation event being sent twice on a single shortcut press. I'm not entirely happy about nested ifs, but AFAIK it's not possible to use if let and a conditional in one line.

I'm a newcomer to Rust, so I'd be grateful for feedback for improvements.


  • ./mach build -d does not report any errors

  • ./mach build-geckolib does not report any errors

  • ./mach test-tidy does not report any errors

  • These changes fix #20478

  • There are tests for these changes OR

  • These changes do not require tests because the change is trivial.


This change is Reviewable

@highfive
Copy link

highfive commented Apr 12, 2018

Thanks for the pull request, and welcome! The Servo team is excited to review your changes, and you should hear from @Manishearth (or someone else) soon.

@highfive
Copy link

highfive commented Apr 12, 2018

Heads up! This PR modifies the following files:

Copy link
Contributor

paulrouget left a comment

We need to do the same thing for the other bindings too. Like reload, loadurl, Cmd-Q, …

if let Some(id) = self.browser_id {
let event = WindowEvent::Navigation(id, TraversalDirection::Forward(1));
self.event_queue.push(event);
if state != KeyState::Released {

This comment has been minimized.

@paulrouget

paulrouget Apr 12, 2018

Contributor

== Pressed instead?

This comment has been minimized.

@piotr-szpetkowski

piotr-szpetkowski Apr 12, 2018

Author Contributor

I've followed the suggestion of @cbrewster that both KeyState::Repeated and KeyState::Pressed might be a valid state and therefore to check for state not being equal to KeyState::Released - #20478 (comment)

@piotr-szpetkowski
Copy link
Contributor Author

piotr-szpetkowski commented Apr 12, 2018

@paulrouget is it desirable to disallow the KeyState::Released for all of the input processed by handle_key_from_window or would you rather see it as an individual decision for each of the match arms?

@Manishearth
Copy link
Member

Manishearth commented Apr 12, 2018

@highfive highfive assigned paulrouget and unassigned Manishearth Apr 12, 2018
@paulrouget
Copy link
Contributor

paulrouget commented Apr 13, 2018

@piotr-szpetkowski You'll see that in handle_key_from_window, in the _ branch of the main match, that events are sent to Servo as WindowEvent::KeyEvent if they are not used in any of the other branch. So we can't have a global check. We will need individual checks.

For the record: Servo will never receive these key events ever. Even if 1) it's no-op (if we press a goForward binding, but we know we can't go forward), and 2) on Release.

@paulrouget
Copy link
Contributor

paulrouget commented Apr 20, 2018

@piotr-szpetkowski let me know if you need help moving forward.

@piotr-szpetkowski piotr-szpetkowski force-pushed the piotr-szpetkowski:master branch 2 times, most recently from 2ba7c25 to 270fddb Apr 21, 2018
@piotr-szpetkowski
Copy link
Contributor Author

piotr-szpetkowski commented Apr 21, 2018

@paulrouget I've updated my PR and it should (hopefully) comply with your review. I've changed the if expression into the match guard, which seems cleaner to me and I've also added it to every other match branch except the _. Sorry I didn't take care of this earlier, but I've been extremely short on spare time during the week.

@bors-servo
Copy link
Contributor

bors-servo commented Apr 25, 2018

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

@piotr-szpetkowski piotr-szpetkowski force-pushed the piotr-szpetkowski:master branch from 270fddb to f45c1be Apr 25, 2018
@paulrouget
Copy link
Contributor

paulrouget commented Apr 28, 2018

Looks better. Can you rebase and use == Pressed instead of != Released?

@jdm
Copy link
Member

jdm commented May 22, 2018

@piotr-szpetkowski Will you have time to address Paul's last comment?

@piotr-szpetkowski
Copy link
Contributor Author

piotr-szpetkowski commented May 22, 2018

Hi @jdm - I'll be able to take care of it on this Friday's evening or Saturday. Also, I've finally finished dealing with real life stuff, so I should have more of a spare time 🙂
Sorry for the amount of time it takes to close the issue.

@piotr-szpetkowski piotr-szpetkowski force-pushed the piotr-szpetkowski:master branch from f45c1be to 03819a5 May 28, 2018
@piotr-szpetkowski piotr-szpetkowski force-pushed the piotr-szpetkowski:master branch from 03819a5 to 3840687 May 31, 2018
@piotr-szpetkowski
Copy link
Contributor Author

piotr-szpetkowski commented May 31, 2018

Hey @paulrouget - I've applied your change request and rebased from master. I've already done it few days ago, but I've forgot to poke you about it, so here, I've rebased once again now and awaiting review.

Copy link
Contributor

paulrouget left a comment

Thank you for the update.

self.event_queue.push(WindowEvent::Quit);
}
(_, Some('3'), _) if mods ^ KeyModifiers::CONTROL == KeyModifiers::SHIFT => {
(_, Some('3'), _) =>
if state == KeyState::Pressed && mods ^ KeyModifiers::CONTROL == KeyModifiers::SHIFT {

This comment has been minimized.

@paulrouget

paulrouget Jun 1, 2018

Contributor

Because you moved the modifier check after =>, it means that just pressing "3" will never make it to Servo.

Keep the modifier check before =>.

@bors-servo
Copy link
Contributor

bors-servo commented Jul 30, 2018

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

@paulrouget
Copy link
Contributor

paulrouget commented Jul 31, 2018

#21250 fixed this.

@paulrouget paulrouget closed this Jul 31, 2018
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.

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