-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Fix escape handling #85438
Conversation
Some changes occurred in HTML/CSS/JS. |
There was a problem hiding this 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")) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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. :)
There was a problem hiding this comment.
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 &&
.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
@bors r+ |
📌 Commit d314b06 has been approved by |
@bors rollup |
… 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`
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
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 returnnull
, which coerces intofalse
with the!
comparison operator. But even if it returnedfalse
, 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