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

Fix escape handling #85438

Merged
merged 2 commits into from
May 19, 2021
Merged

Fix escape handling #85438

merged 2 commits into from
May 19, 2021

Conversation

GuillaumeGomez
Copy link
Member

@GuillaumeGomez GuillaumeGomez commented May 18, 2021

Currently, when we press Escape while on the search results, nothing is happening, this PR fixes it.

More information: it's because in case the element doesn't exist, hasClass will return null, which coerces into false with the ! comparison operator. But even if it returned false, it would still be an issue because if the element doesn't exist, it means it's hidden so in this case it's just as good, hence the additional check I added.

r? @jsha

@rust-highfive
Copy link
Collaborator

Some changes occurred in HTML/CSS/JS.

cc @GuillaumeGomez

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 18, 2021
Copy link
Contributor

@jsha jsha left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for finding and fixing! I am a bit mystified about how this fix works though.

@@ -428,9 +428,9 @@ function hideThemeButtonState() {
function handleEscape(ev) {
var help = getHelpElement(false);
var search = searchState.outputElement();
if (!hasClass(help, "hidden")) {
if (help && !hasClass(help, "hidden")) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hasClass is defined like so:

function hasClass(elem, className) {
    return elem && elem.classList && elem.classList.contains(className);
}

So I think this should be redundant. Can you explain (in the PR description) what the bug was and how this fixes?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's simply because if the element doesn't exist, it doesn't have the class and enter the condition. :)

Copy link
Contributor

@pickfire pickfire May 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about other cases? I don't see the first help && part, some of them have this and some does not. Seemed confusing to me.

Others may easily make a mistake here later. I see quite a few hasClass and roughly half of them have the first help && .

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha, now I see the issue. The problem is that these if clauses are exclusive. So we were mistakenly executing the "hide help" clause, which prevented us from executing the "hide search" clause.

What about making both of these clauses unconditional? If you hit escape, it's reasonable to try and hide the help, and also try and hide the search. Worst case, it's a no-op.

Relatedly: Why does only the search clause have a preventDefault()? Do we need a preventDefault() at all here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, we might want to close the help without closing the search results (my GUI test actually enforces this behaviour). Also, this change is mostly because of the migration of the boolean comparison. With === false, it wouldn't enter because hasClass would return null.

As for preventDefault, no idea. Can be removed I think.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now I fully understand. Thanks for explaining.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pickfire Well, not really, in case we want to check that if the element exists, it's hidden, if it doesn't exist then it's all good. You can see it as follows too: if the element doesn't exist, it doesn't implement the class. 😃

@jsha I'll open an issue to make another cleanup round around hasClass usage just in case.

@jsha
Copy link
Contributor

jsha commented May 18, 2021

@bors r+

@bors
Copy link
Contributor

bors commented May 18, 2021

📌 Commit d314b06 has been approved by jsha

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 18, 2021
@GuillaumeGomez
Copy link
Member Author

@bors rollup

Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request May 18, 2021
… r=jsha

Fix escape handling

Currently, when we press Escape while on the search results, nothing is happening, this PR fixes it.

More information: it's because in case the element doesn't exist, `hasClass` will return `null`, which coerces into `false` with the `!` comparison operator. But even if it returned `false`, it would still be an issue because if the element doesn't exist, it means it's hidden so in this case it's just as good, hence the additional check I added.

r? `@jsha`
bors added a commit to rust-lang-ci/rust that referenced this pull request May 19, 2021
Rollup of 8 pull requests

Successful merges:

 - rust-lang#83366 (Stabilize extended_key_value_attributes)
 - rust-lang#83767 (Fix v0 symbol mangling bug)
 - rust-lang#84883 (compiletest: "fix" FileCheck with --allow-unused-prefixes)
 - rust-lang#85274 (Only pass --[no-]gc-sections if linker is GNU ld.)
 - rust-lang#85297 (bootstrap: build cargo only if requested in tools)
 - rust-lang#85396 (rustdoc: restore header sizes)
 - rust-lang#85425 (Fix must_use on `Option::is_none`)
 - rust-lang#85438 (Fix escape handling)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 6cfcbf7 into rust-lang:master May 19, 2021
@rustbot rustbot added this to the 1.54.0 milestone May 19, 2021
@GuillaumeGomez GuillaumeGomez deleted the fix-escape-handling branch May 19, 2021 08:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants