68403 - W3C CUAP: Indicate missing or broken anchors on click

Status: NEW

(Core :: Layout, defect, P3)

Description

[Gervase Markham [:gerv]]

[ This bug is one of the recommendations in the W3C's "Common User Agent 
Problems" document, URL above. One bug has been filed on each recommendation, 
for deciding whether we do it and, if not, whether we should. ]

1.2 If the user attempts to follow a link that is broken because it
designates a missing anchor, let the user know it is broken.

     There are many ways to indicate to the user that a link is broken. The
     recommended behavior is as follows:

        o Do not scroll or otherwise change the viewport. This could make
          the user believe the link is not broken.
        o Indicate to the user (e.g., via a text message in the status bar)
          that the link is broken. If no message is given to the user, they
          will not understand why the viewport didn't move.
        o Ensure that any non-text message to the user has a text
          equivalent; text may be rendered as visually displayed text,
          synthesized speech, and braille. Audio cues or visual cues may be
          used in addition to text messages.

     Wrong: Some user agents scroll to the top or bottom of the document
     when the user attempts to follow a broken link. This behavior is
     discouraged since it is indistinguishable from the correct behavior
     when a target is at the beginning or end of a document.

Comment 1

[Matthew T (active 1999-2002)]

Instead of saying `Done' (bug 48436), the status bar in this situation could say 
`Done, but anchor was not found'.

Comment 2

[Jesse Ruderman]

Or maybe "Done, but anchor 'foo' not found", so users aren't left wondering 
what an anchor is.

If the anchor is within the same page, should the status bar text still 
include "Done"?

Comment 3

[Stephan Niemz]

Attachment: test case

Comment 4

[Jesse Ruderman]

That testcase covers the same-page case, but I think the W3C intended for the 
recommendation to also apply to links pointing to named anchors in another 
document.

Comment 5

[Zach Lipton [:zach]]

Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...

Comment 6

[Asa Dotzler [:asa]]

updating to new owner. sorry for the spam.

Comment 7

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 115458 has been marked as a duplicate of this bug. ***

Comment 8

[xyzzy]

If bug 115458 is a dup of this, then this bug should address blocked image links
as well.

Suggest summary "W3C CUAP: Indicate missing/broken/blocked anchors on click".

Comment 9

[Jonas Jørgensen]

.

Comment 10

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Adam, do you still own this code? Seems like this would be easy to fix...

Comment 11

[Adam Lock]

Code that does the scrolling is in nsDocShell::ScrollIfAnchor. It doesn't
actually know whether the anchor is valid or not and simply prepares the string
that it passes to nsIPresShell::GoToAnchor to do the scrolling.

http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsPresShell.cpp#3934

This code is pretty complicated, but assuming it returns an error rv when the
anchor cannot be found, it may be possible to put something in the status bar,
or system beep or something.

Note, the anchor code in docshell is only invoked when clicking on an anchor in
the current page. Anchor scrolling happens via an HTTP request, scrolling is
triggered from the HTML content sink. The HTML content sink repeatedly tries to
call nsIPresShell::GoToAnchor, so any "does not exist" error would have to be
supressed until page loading has completed.

http://lxr.mozilla.org/seamonkey/source/content/html/document/src/nsHTMLContentSink.cpp#4302