This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4007 - Fragment reporting - reporting broken fragment when link (URI and Fragment) is not broken
Summary: Fragment reporting - reporting broken fragment when link (URI and Fragment) i...
Status: RESOLVED INVALID
Alias: None
Product: LinkChecker
Classification: Unclassified
Component: checklink (show other bugs)
Version: 4.2.1
Hardware: All Linux
: P2 normal
Target Milestone: ---
Assignee: Ville Skyttä
QA Contact: qa-dev tracking
URL: http://www.amd.com/us-en/Weblets/0,,7...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-24 04:56 UTC by Bruce Altmann
Modified: 2006-11-24 17:51 UTC (History)
0 users

See Also:


Attachments

Description Bruce Altmann 2006-11-24 04:56:21 UTC
(I checked for a similar bug. I see comment about fragment reporting, but all of those show the source has valid broken fragments.)

If you run the CGI verison (or my local Linux 4.2.1 version w some patches) on 
this example page
http://www.amd.com/us-en/Weblets/0,,7832_11104_11105,00.html

Get the same result.

Shows 3 broken fragments. (not just list 3 found fragments)

But if click on the fragments on the CGI results screen, the link works (it is a link#frag).
I have checked the source. (you can view source as well)
Seems to be a reptative error.

Please advise.
Is this an error. If yes, any idea what is happening during the broken $f check.
Comment 1 Ville Skyttä 2006-11-24 17:51:43 UTC
The target document for the fragments, http://www.amd.com/us-en/Weblets/0,,7832_11104_11106,00.html , has a XHTML doctype declaration which causes the link checker to parse the document in XML mode, which is case sensitive.

The target document uses quite a few uppercase tag names, also in the "consumer" case:

    <A name="consumer"></a>

"A" is not a valid XHTML element, and therefore the no anchors are searched within its attributes.  Changing "<A" to "<a" could work around this particular problem, but the document source looks like it could use more thorough XHTML fixes (eg. starting with lowercasing a lot of things) to prevent other future surprises.