197607 - Link to <a name> location doesn't jump to target text when opened in new window, tab, or loaded from another document.

Status: VERIFIED FIXED

(SeaMonkey :: General, defect)

Description

[Jason Bassford]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030315
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030315

My apologies for not really knowing how to phrase this report or pick an
appropriate component.

When left-clicking on a link that refers to an <a name> piece of code, the
browser view jumps to that position on the page as you'd expect.

However, when opening the same link in a new window or tab, the browser position
is at the TOP of the document, not at the position where then named target is
located.

Reproducible: Always

Steps to Reproduce:
1. Load the testcase which I will attach in a follow-up comment.
2. Left-click on the link.  The browser jumps to the target location.
3. Go back.  Now right-click on the link and open it in a new window or tab.

Actual Results:  
The document is loaded, with the browser scrolled to the top of the page.

Expected Results:  
The document should be loaded with the browser scrolled to the point in the page
where the named target text is located.

I'm not sure if this is a bug, an enhancement request, or even if it's a dupe of
something else which I've been unsure of how to search for.  (Searching for "a
name" produced nothing.)

Comment 1

[Jason Bassford]

Attachment: Testcase for <a name> target link.

This is really bad HTML coding, but should get the point across.

Comment 2

[James Graham]

Attachment: Second testcase

Actually, it seems to be worse - the browser will only jump to the fragment if
it's part of the document already loaded in the tab / window in which the URI
is being loaded. The testcase attached demonstrates this - open the link in the
current tab and the first testcase will load but not at the 'jump' fragment.

I see this with 2003031405/linux. The most obvious related checkin on 20030313
is bug 197277

Comment 3

[James Graham]

Adding bzbarsky to cc list in case it is his checkin that broke this. Sorry if
that's an inappropriate thing to do.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

hm, I have noticed this as well, linux current trunk.

Comment 5

[Jason Bassford]

Adding keyword.  (Since from comments this seems to be legitimate regression - I
wasn't sure.)

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I can't reproduce this problem on 2003031604-trunk/WinXP.

Comment 7

[James Graham]

This does indeed appear to be fixed using 2003031605/linux. It appears dbaron
checked in a fix via bug 197277. 

Comment 8

[Boris Zbarsky [:bzbarsky]]

Yeah, dbaron's checkin fixed this.  My apologies for the screwup....

Comment 9

[James Graham]

Actually I still observe one problem:

1. Follow a link to a target location on a new page (in the current window/tab)
e.g. using the second testcase above
2. Go back
3. Go forward again - you will be at the top of the page and not at the correct
target

Comment 10

[Jason Bassford]

Verified fixed.  R.e. comment 9, I believe that this should be filed as a
different bug relating to history.

Comment 11

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

Bug 197823 was spun off.