-
Notifications
You must be signed in to change notification settings - Fork 356
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
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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)); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. cc @alflennik I also removed |
||
} | ||
|
||
const isLinkBroken = !( | ||
|
@@ -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' | ||
|
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.
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.
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.
Done in 56d93db