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

Infrastructure: link-checker.js: Check if any of the known pageIds include the hash being checked for #2812

Merged
merged 3 commits into from
Oct 2, 2023

Conversation

howard-e
Copy link
Contributor

@howard-e howard-e commented Sep 25, 2023

Closes #2809. Follow up on my thoughts in #2809 (comment).

Should this explicitly check for user-content- when checking GitHub links instead?


WAI Preview Link (Last built on Mon, 02 Oct 2023 13:59:20 GMT).

@howard-e howard-e added the Infrastructure Related to maintaining task force and repo operations, processes, systems, documentation label Sep 25, 2023
@@ -227,7 +227,7 @@ async function checkLinks() {

let matchesHash = true;
if (hash) {
matchesHash = !!matchingPage?.ids.includes(hash);
matchesHash = !!matchingPage?.ids.some((id) => id.includes(hash));
Copy link
Contributor

Choose a reason for hiding this comment

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

Since it's not checking that the ID is exact I think an explanatory comment might be warranted, especially one that explains that this reproduces the behavior already present in GitHub.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done in 56d93db

Copy link
Contributor

@alflennik alflennik left a comment

Choose a reason for hiding this comment

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

That was a really helpful comment, I didn't know that!

Copy link
Contributor

@mcking65 mcking65 left a comment

Choose a reason for hiding this comment

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

@howard-e

Thank you for the investigation and the Fix! I would like to tighten up the conditions. see my comment in the code.

// as being user-content-foo-bar for its own page processing purposes.
//
// See https://github.com/w3c/aria-practices/issues/2809
matchesHash = !!matchingPage?.ids.some((id) => id.includes(hash));
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this condition is not sufficiently restrictive. It makes it too easy for me (and others) to create href attributes that are not valid. I really want to be confident that our content does not contain invalid fragment ids. Even though there is the possibility of more maintenance to this code, I'd rather have the condition be specific to GitHub pages and the "user-content-" prefix. It does not seem likely we will encounter this problem on other pages referenced by the APG.

Over time, if it turns out GitHub is wishywashy in there approach or if this turns out to be a problem with other sites, we can decide how to address those other scenarios when they arise.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@mcking65 I've updated the code to account specially account for this GitHub scenario.

I also set it up to handle any others in the future using the .link-checker.js file which seems to handle some config settings.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

cc @alflennik I also removed /^https:\/\/github\.com\/.*\/wiki\// from ignoreHashesOnExternalPagesMatchingRegex as the same situation would happen on those wiki pages.

Copy link
Contributor

@mcking65 mcking65 left a comment

Choose a reason for hiding this comment

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

Thank you @howard-e! Looks great.

@mcking65
Copy link
Contributor

mcking65 commented Oct 2, 2023

Thank you @howard-e and @alflennik

@mcking65 mcking65 merged commit f97050b into main Oct 2, 2023
7 checks passed
@mcking65 mcking65 deleted the linkchecker-hash-check branch October 2, 2023 19:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Infrastructure Related to maintaining task force and repo operations, processes, systems, documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

link-checker incorrectly says a fragment does not exist
3 participants