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
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 15 additions & 2 deletions scripts/link-checker.js
Original file line number Diff line number Diff line change
Expand Up @@ -227,7 +227,16 @@ async function checkLinks() {

let matchesHash = true;
if (hash) {
matchesHash = !!matchingPage?.ids.includes(hash);
// On some websites, the ids may not exactly match the hash included
// in the link.
// For e.g. GitHub will prepend client facing ids with their own
// calculated value. A heading in a README for example could be
// Foo bar, navigated to with https://github.com/foo/bar#foo-bar,
// but GitHub calculates the actual markup id included in the document
// 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.

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

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.

}

const isLinkBroken = !(
Expand Down Expand Up @@ -274,7 +283,11 @@ async function checkLinks() {
hrefOrSrc.match(pattern)
);

if (!isHashCheckingDisabled && hash && !pageData.ids.includes(hash)) {
if (
!isHashCheckingDisabled &&
hash &&
!pageData.ids.some((id) => id.includes(hash))
) {
consoleError(
`Found broken external link on ${htmlPath}:${lineNumber}:${columnNumber}, ` +
'hash not found on page'
Expand Down