Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED in mozilla0.9.6

Status

()

Core
Layout
RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: mkaply, Assigned: Kevin McCluskey (gone))

Tracking

({top100, topembed})

Trunk
mozilla0.9.6
top100, topembed
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [EDT+][PDT-] [quirks][bugscape: 10365][beppe:101201][CANDIDATE_094] Checked into the trunk and 094 branch, URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

16 years ago
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

16 years ago
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.
Summary: #top named anchor doesn't work → #top named anchor doesn't work of no <a name="top"> present
(Reporter)

Comment 2

16 years ago
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

16 years ago
*** Bug 86074 has been marked as a duplicate of this bug. ***
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

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

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.
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?
(Reporter)

Comment 8

16 years ago
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.
Keywords: 4xp

Comment 9

16 years ago
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

16 years ago
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.

Updated

16 years ago
Summary: #top named anchor doesn't work of no <a name="top"> present → WRMB: #top named anchor doesn't work of no <a name="top"> present
Whiteboard: [bugscape: 7514]

Comment 11

16 years ago
Changed Bugscape bug to metabug 10365.
Whiteboard: [bugscape: 7514] → [bugscape: 10365]

Comment 12

16 years ago
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
Keywords: topembed

Comment 13

16 years ago
Kevin, Marc and I aren't sure who to reassign this to.
Assignee: karnaze → kmcclusk
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

16 years ago
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
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

16 years ago
Yes, section 12 discusses this, please see my previous comment
Section 12 is quite large, and I didn't see anything in it supporting that comment.
(Assignee)

Comment 19

16 years ago
CC'ing sarri, joki since scrolling to a named anchor is done by changing focus
to frame with the named anchor. 
(Reporter)

Comment 20

16 years ago
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

16 years ago
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
(Assignee)

Updated

16 years ago
Target Milestone: --- → mozilla0.9.6
(Reporter)

Comment 22

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

Let's call #top an internal anchor.

Comment 23

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

Comment 24

16 years ago
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

16 years ago
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.
(Reporter)

Comment 26

16 years ago
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

16 years ago
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

16 years ago
Actually, the not scrolling to top is bugzilla bug 68434

Comment 29

16 years ago
whiteboard garbage
Whiteboard: [bugscape: 10365] → [quirks][bugscape: 10365][beppe:101201]
(Assignee)

Comment 30

16 years ago
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.
Assignee: kmcclusk → joki
(Assignee)

Comment 31

16 years ago
Taking bug back, Tom is on vacation.
Assignee: joki → kmcclusk
(Assignee)

Comment 32

16 years ago
Created attachment 53814 [details] [diff] [review]
Scroll window to top/left if an anchor can not be found (Quirks mode only)
(Assignee)

Updated

16 years ago
Whiteboard: [quirks][bugscape: 10365][beppe:101201] → [quirks][bugscape: 10365][beppe:101201] Fix in hand waiting for r/sr
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 33

16 years ago
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/

Keywords: top100

Comment 34

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

sr=attinasi
Attachment #53814 - Flags: superreview+

Comment 35

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

r=kin@netscape.com

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);
Attachment #53814 - Flags: review+
(Assignee)

Updated

16 years ago
Whiteboard: [quirks][bugscape: 10365][beppe:101201] Fix in hand waiting for r/sr → [quirks][bugscape: 10365][beppe:101201] Read to check in
(Assignee)

Comment 36

16 years ago
Marking nsbranch+
Keywords: nsbranch+
(Assignee)

Comment 37

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

Updated

16 years ago
Whiteboard: [quirks][bugscape: 10365][beppe:101201] Read to check in → [quirks][bugscape: 10365][beppe:101201][CANDIDATE_094] Checked into the trunk
(Assignee)

Comment 38

16 years ago
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. 
(Assignee)

Comment 39

16 years ago
Created attachment 53901 [details] [diff] [review]
scroll to the top/left only if  the anchor name is top

Comment 40

16 years ago
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...)
Attachment #53901 - Flags: superreview+

Comment 41

16 years ago
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

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

r=kin@netscape.com

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?
Attachment #53901 - Flags: review+

Comment 43

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
I'm confused. we put 404 urls into history, don't we? -- we do in 0.9.5
> 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

(Assignee)

Comment 48

16 years ago
Created attachment 54220 [details] [diff] [review]
Ignore case when comparing "top"
(Assignee)

Updated

16 years ago
Attachment #53901 - Attachment is obsolete: true

Comment 49

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

r/sr=kin@netscape.com
Attachment #54220 - Flags: superreview+

Comment 50

16 years ago
PDT- For this week, but it can be picked up for embedding next week if they'd like.
Whiteboard: [quirks][bugscape: 10365][beppe:101201][CANDIDATE_094] Checked into the trunk → [PDT-] [quirks][bugscape: 10365][beppe:101201][CANDIDATE_094] Checked into the trunk

Comment 51

16 years ago
r=rods (looks good)
(Assignee)

Comment 52

16 years ago
checked patch 54220 into trunk

Updated

16 years ago
Blocks: 107066

Comment 53

16 years ago
adding EDT+ (first usage of it :-)). please proceed w/ 0.9.4 branch checkin.
Whiteboard: [PDT-] [quirks][bugscape: 10365][beppe:101201][CANDIDATE_094] Checked into the trunk → [EDT+][PDT-] [quirks][bugscape: 10365][beppe:101201][CANDIDATE_094] Checked into the trunk
(Assignee)

Comment 54

16 years ago
Checked into 094 branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Whiteboard: [EDT+][PDT-] [quirks][bugscape: 10365][beppe:101201][CANDIDATE_094] Checked into the trunk → [EDT+][PDT-] [quirks][bugscape: 10365][beppe:101201][CANDIDATE_094] Checked into the trunk and 094 branch

Comment 55

16 years ago
Just wanted to say THANKS for getting this done. It has fixed anchors on
Fidelity.com as well. :-) Works for me! (build 2001112003)
You need to log in before you can comment on or make changes to this bug.