80784 - WRMB: #top named anchor doesn't work of no <a name="top"> present

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Mike Kaply [:mkaply]]

Although I can't find it in spec, it appears that IE and NS 4.x had a default 
named anchor of #top that would always take you to the top of the page:

<A href="#top>Go to the top of the page</A>

This doesn't work in Mozilla (0.6 or current builds).
I'm not sure if it ever worked along the way.

Scroll to the bottom of the testcase and click on the last link.

Comment 1

[Boris Zbarsky [:bzbarsky]]

actually, IE and NS4.x will scroll to top for _any_ unknown anchor.  try <a
href="#foo"> if you like.

We just ignore the anchor if it's not in the document -- this seems like better
behavior....

See also bug 80346.

Comment 2

[Mike Kaply [:mkaply]]

Actually, only NS 4.x scrolls on any anchor.

IE only scrolls to the top on #top.

80346 was marked invalid, but I'm not sure that this is the right answer. Do we 
know if this behavior is documented anywhere?

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[Christopher Hoess (gone)]

Since RFC 2396 disclaims the fragment identifier as part of the URI, I would 
suggest that the handling of such a URI be theoretically treated in two steps:
1) Load base URI (URI of current document), action uniform to all URIs.
2) Handle fragment identifier within context of loaded document (an action well-
defined for HTML documents).

Based on this model, I would suggest that the behavior of links with href=
"(current document)", href="(current document)#nonexistant anchor", href=
"#nonexistant anchor", and (as a bonus) href="" all be treated in the same 
manner. [From RFC 2396: "If the path component is empty and the scheme, 
authority, and query components are undefined, then it is a reference to the 
current document and we are done."  That is to say, an anchor with href="" points 
to a relative URI which expands into the absolute URI of the current document.]

I tend to feel that this behavior should be as in NS 4.x, i.e., the position 
within the document returns to the default at the top when clicking the link, and 
remains there because the fragment identifier is meaningless.

CCing dbaron, for more informed commentary and better logic.

Comment 5

[ravi]

this seems a duplicate of 68434 (dont know if pointing out
duplicates is an appropriate thing for me - end user - to
do).

Comment 6

[Christopher Hoess (gone)]

See bug 93077, where this issue has been closed as INVALID.  This bug should 
probably get the same, since there's a very simple workaround.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Didn't NN4 make any named anchor it couldn't find go to the top of the page? 
(i.e., is "top" not special?)  Does IE do the same thing?

Comment 8

[Mike Kaply [:mkaply]]

If a company has deployed 10,000 web pages that rely on this behavior, there is 
no such thing as a "simple workaround"

I'm marking this 4xp.

Comment 9

[Dennis Kehrig]

At least in Netscape 4 the page won't scroll to the top of the page like it
would do by using the scrollbar IF AN ANCHOR IS DEFINED. If the page has an
standard margin of, say, 5 pixels, the document will actually be scrolled down
by 5 pixels after you clicked the link to #top. To be able to go to the absolute
top, 0 pixels, you have to use an undefined anchor, JavaScript, or no margin
which influences the rest of the page as well. Therefore Mozilla should behave
like NS 4 and IE do: scroll up as far as it can.
Win98/0.9.4

Comment 10

[rubydoo123]

Looking at the HTML spec, specifically section 12 it states:

12.2.4 Unavailable and unidentifiable resources

A reference to an unavailable or unidentifiable resource is an error. Although 
user agents may vary in how they handle such an error, we recommend the 
following behavior:

* If a user agent cannot locate a linked resource, it should alert the user. 
* If a user agent cannot identify the type of a linked resource, it should still 
attempt to process it. It should alert the user and may allow the user to 
intervene and identify the document type. 

I do not see where it states that the user agent should default to the top. 
Where is that stated in the spec? It seems that this bug should be marked as 
invalid in regard to the information in the above section.

Comment 11

[Susie Wyshak]

Changed Bugscape bug to metabug 10365.

Comment 12

[Susie Wyshak]

For some reason there are HTML developers who have counted on not needing to
include <a name="top"> -- perhaps because IE, N4.x, and even Opera 5 take the
user to the top of the page when <a name="top"> is not present. While this isn't
a WC3 standard it seems to be a non-standard standard. 

So my suggestion is that when in quirks mode if there is no target for an anchor
link that the Netscape 4.x behavior take effect. 

This will prevent user inconvenience and resulting calls to website customer
support reporting these broken links. 
Another example: http://people.aol.com/people/index.html

Comment 13

[karnaze (gone)]

Kevin, Marc and I aren't sure who to reassign this to.

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Why only quirks mode?  We should only diverge when a standard clearly says that
we can't do what we want to do in quirks mode, and I don't know of anything that
says that.

Comment 15

[rubydoo123]

What do you mean David? Are you suggesting that we have the same behavior in 
strict mode as well?

I discussed this with WG members and the response to this "problem" was this:
1. strictly following the spec, we should display a 404 error message
2. a moderate approach would be to silently fail
3. the wrong approach would be to do what is requested for this bug

I would be against allowing #3 in strict mode

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

What part of the HTML spec overrides what choess says about RFC 2396 above?  The
RFC should be authoritative on how to interpret URLs, unless the HTML spec says
something specific about how to handle undefined fragments within HTML documents.

Comment 17

[rubydoo123]

Yes, section 12 discusses this, please see my previous comment

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Section 12 is quite large, and I didn't see anything in it supporting that comment.

Comment 19

[Kevin McCluskey (gone)]

CC'ing sarri, joki since scrolling to a named anchor is done by changing focus
to frame with the named anchor. 

Comment 20

[Mike Kaply [:mkaply]]

Actually, in looking at section 12, this says top to me:

* If a user agent cannot identify the type of a linked resource, it should still 
attempt to process it. 

So we cannot identify the anchor, but we know what they meant so we attempt to 
process it by going to #top.

This is a classic case of "undefined" Is there somewhere in a spec that says 
#top should not go to the top? Is there somewhere in a spec that says #top 
should go to the top?

Sometimes we just have to bite the bullet and accept that something has become a 
defacto standard.

Otherwise people will just interpret our browser as broke.

Comment 21

[rubydoo123]

this is a response from the W3C:

There is a good W3C Note that all UA implementors should read, Common User Agent 
Problems. In point 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." 
<http://www.w3.org/TR/cuap#usability> says:

    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.

Recommendation: mark this bug as invalid or won't fix

Comment 22

[Mike Kaply [:mkaply]]

OK, let's not call #top a broken link then.

Let's call #top an internal anchor.

Comment 23

[rubydoo123]

which is pointing to an invalid named anchor, which makes it a broken link

Comment 24

[Andreas]

Is it really difficult simply to do the scrolling if the link is named "#top"? I
created several pages and i thought it would something like "_new" in the
target... some browser-internal thing. As EVERY Browser except Mozilla DOES a
scrolling to the top... 
 You're right: Really it IS a broken link. But you know where it should go. And
if thousands of pages need to be redesigned because of a behavior exact to the
letter of W3C... many really don't like to use it then, i think.

Comment 25

[rubydoo123]

So, for this new undocumented feature request (bug), should we also read the 
intent of the author if they have an href value of href="#bottom"? Should we 
know that the authro meant to go to the top if they coded href="#to_top"? Or is 
the expectation that we only do this for #top? How would someone know that only 
#top has this super special deal and not others?

Standards compliance is the goal here by the way.

Comment 26

[Mike Kaply [:mkaply]]

Well if standards compliance is the goal, then put it in 
quirks mode as was mentioned earlier.

And as far as what to do - the answer is #top takes you to 
the top. That seems to cover the majority of pages.

I understand the standards compliance tradeoff very well. 
But the most standards compliant browser in the world is 
pretty danged useless if it can't view existing web pages.

Comment 27

[Dennis Kehrig]

Do me a favour:

1. visit http://www.denniskehrig.purespace.de/mozilla/
2. View both files (top-defined.html and top-not-defined.html) with IE, Netscape
4 or Opera.
3. Scroll down to the bottom and click the #top link.

top-defined.html: <A name="top"></A> right after <BODY>
top-not-defined.html: No anchor named "top"

In top-defined.html, you will see the document starting right at the beginning
of the blue box, but the box is some pixels away from the top of the document -
where I intended the link to go to (test it: you can still scroll up after
clicking the link!).
In top-not-defined.html, the 3 mentioned browsers will do what I wanted to
achieve: they go to the beginning of the document, like they do if the document
is opened without an anchor defined. There is no way to achieve this with an
anchor defined, unless you use JavaScript to go up (in which case the anchor
would be useless) or set the top margin of the page to 0px, which requires
different approaches for different browsers, if it works at all.
So simply not defining the anchor is an easy way that worked with every browser
so far. Okay, I could also make an href="" or href="top-defined.html" to
effectively go to the top but this requires the page to be loaded from the
server again and is therefore not an acceptable alternative to a simple scroll.

Mozilla would require pages to be modified in order to make top-links possible
because Mozilla also scrolls to the beginning of the box and not to the
beginning of the document (see top-defined.html).

So please: let Mozilla do what all browsers do - consider an undefined anchor as
a link to the top. The top of the document and not of its first element. This is
even better than the current behaviour of Mozilla (do nothing) since the user
gets a feedback that Mozilla has handled the click.

I mentioned this above as well, I hope it got clearer now.

Comment 28

[rubydoo123]

Actually, the not scrolling to top is bugzilla bug 68434

Comment 29

[rubydoo123]

whiteboard garbage

Comment 30

[Kevin McCluskey (gone)]

I think this bug belongs to joki. Looking at the ScrollTo code it is fired on
the EventStateManager by changing of focus. I'm not sure where the actual code
which locates the frame to scrollTo is found.

Tom: If you don't own this area go ahead and reassign back to me.

Comment 31

[Kevin McCluskey (gone)]

Taking bug back, Tom is on vacation.

Comment 32

[Kevin McCluskey (gone)]

Attachment: Scroll window to top/left if an anchor can not be found (Quirks mode only)

Comment 33

[Kevin McCluskey (gone)]

some sites with nonfunctional "back to top" links: which are fixed by patch 53814

http://www.barnesandnoble.com
http://www.aa.com
http://www.chipsbits.com
http:/www.christianitytoday.com (home page)
http://www.realtor.com
http://www.nba.com
http://www.thestreet.com
http://www.lucent.com
http://www.campuspipeline.com
http://www.mitre.org/

Comment 34

[Marc Attinasi]

Comment on attachment 53814 [details] [diff] [review]
Scroll window to top/left if an anchor can not be found (Quirks mode only)

sr=attinasi

Comment 35

[kinmoz]

Comment on attachment 53814 [details] [diff] [review]
Scroll window to top/left if an anchor can not be found (Quirks mode only)

r=[e-mail]

Not a requirement, but why not just set rv to the return val of
ScrollTo() to catch any errors it might throw?

+        rv = scrollingView->ScrollTo(0, 0, NS_VMREFRESH_IMMEDIATE);

Comment 36

[Kevin McCluskey (gone)]

Marking nsbranch+

Comment 37

[Kevin McCluskey (gone)]

Checked patch (53814) into the trunk.  Mozilla now behaves the same as 4.x in
quirks mode.

Comment 38

[Kevin McCluskey (gone)]

PDT: This small fix is isolated to clicking on a link to a named anchor that
doesn't exist. Previous behavior was to do nothing, new behavior is compatible
with 4.x which is to scrollto the upper left corner. 

Comment 39

[Kevin McCluskey (gone)]

Attachment: scroll to the top/left only if the anchor name is top

Comment 40

[Marc Attinasi]

Comment on attachment 53901 [details] [diff] [review]
scroll to the top/left only if  the anchor name is top

sr=attinasi (though I personally prefer the Nav approach...)

Comment 41

[Marc Attinasi]

I prefer the Nav compatibility personally. The IE method essentially makes the
use of a named anchor #top at a location other than the top dubious. Why do you
want to do the IE version and not the Nav version? It seems that the Nav version
will cover the same sites as the IE version, and has the added benefit of not
making '#top' a special name (it just scrolls to the top for all nonexistant
anchors).

Either way, sr=attinasi

Comment 42

[kinmoz]

Comment on attachment 53901 [details] [diff] [review]
scroll to the top/left only if  the anchor name is top

r=[e-mail]

The patch looks fine to me, though I kind of agree with Marc.

Are we sure that we aren't going to break any important sites that rely
on the 4.x behavior?

Comment 43

[rubydoo123]

We discussed this issue in the W3C HTML WG teleconference today. I wanted to 
convey to you via the bug what the W3C HTML WG had to say about this:
1. regardless as to what we do, the history stack should not be corrupted with 
the resulting jump to the top

2. treating #top as an exception, if necessary, is at least tolerable as long as 
other unknown links are not treated the same. It can easily be inferred that 
#top was meant, by the author, to go to the top. But other invlaid named anchor 
links should not be interpreted the same way. The UA should not interpret the 
authors intent with other named anchor links. The UA response on other #whatever 
links should be to either silently ignore, or provide user feedback that lets 
them know the named anchor can not be found.

Comment 44

[Marc Attinasi]

If #top is easily inferred to mean the top of the document, then why not support
#bottom too? What I dislike most about the argument (that 'top' can be infered
to mean the top of the document) is that it does not address the fact that an
author may actually choose to put a valid named anchor called 'top' anywhere,
and so 'top' becomes somewhat ambiguous - sometimes it means jump to the top of
the page, sometimes it means jump to some other location where the anchor is.

Also, what is the reason for NOT putting the jump in the history? If we jump to
the top, then to another location, shouldn't back return us to the top? I don't
understand the value in keeping that out of the history.

Anyway, thanks for the WG clarification Beth.

Comment 45

[rubydoo123]

The discussion was that the link was invalid, therefore it should not be added 
to the stack. Like any other invalid link, this particular link should not alter 
the history stack. The choice to honor the invalid link instead of ignoring it 
is an implementation decision and not a recommendation. 

Comment 46

[timeless]

I'm confused. we put 404 urls into history, don't we? -- we do in 0.9.5

Comment 47

[Gervase Markham [:gerv]]

> If #top is easily inferred to mean the top of the document, then why not support
> #bottom too? 

Because no-one is using #bottom on the web without setting <a name="bottom>. 

Like many of our quirks, this is a quirk to work around a common, yet incorrect,
authoring practice on the web, while following the standards as much as
possible. kmcclusk's latest patch does exactly that.

We should, however, document this behaviour in the same place that we document
all our other quirks so that web authors know about them. We do do that, right?

Oh - if it's not too late, can we use EqualsIgnoreCase, if there is such a
method? Kat Momoi was telling me that MSFT have a related problem - they have <a
href="#TOP"> at the bottom and <a name="top> at the top of the document, and our
current anchor code is case-sensitive.

Gerv

Comment 48

[Kevin McCluskey (gone)]

Attachment: Ignore case when comparing "top"

Comment 49

[kinmoz]

Comment on attachment 54220 [details] [diff] [review]
Ignore case when comparing "top"

r/sr=[e-mail]

Comment 50

[Jaime Rodriguez, Jr.]

PDT- For this week, but it can be picked up for embedding next week if they'd like.

Comment 51

[rods (gone)]

r=rods (looks good)

Comment 52

[Kevin McCluskey (gone)]

checked patch 54220 into trunk

Comment 53

[Judson Valeski]

adding EDT+ (first usage of it :-)). please proceed w/ 0.9.4 branch checkin.

Comment 54

[Kevin McCluskey (gone)]

Checked into 094 branch.

Comment 55

[Susie Wyshak]

Just wanted to say THANKS for getting this done. It has fixed anchors on
Fidelity.com as well. :-) Works for me! (build 2001112003)