Clicking on anchor goes to top of page, entering the URL directly doesn't

VERIFIED FIXED in mozilla1.0

Status

()

Core
Document Navigation
P1
critical
VERIFIED FIXED
16 years ago
10 years ago

People

(Reporter: A. Craig West, Assigned: Aaron Leventhal)

Tracking

({regression, topembed+})

Trunk
mozilla1.0
regression, topembed+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
If you go to the above URL, which is to an anchor in the Java documentation, the
browser brings up the page scrolled to the anchor correctly. If you click on the
link to the same anchor on the page the browser scrolls to the top of the page,
instead. The link to the anchor can be found in the 'Method Index' section, it
is the last link in that section.
This applies to all links in the Java documentation, at least.
I've been seeing this in current builds on Linux as well...

session history
Assignee: asa → radha
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: Browser-General → History: Session
Ever confirmed: true
Keywords: regression
OS: Windows 2000 → All
QA Contact: doronr → claudius
Hardware: PC → All

Comment 2

16 years ago
*** Bug 130449 has been marked as a duplicate of this bug. ***
*** Bug 130555 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0, nsbeta1

Updated

16 years ago
Blocks: 124273
*** Bug 131814 has been marked as a duplicate of this bug. ***
This is happening all over, on a variety of pages... QA is very hard when you
can't navigate the W3C specs....
Severity: major → critical
cc'ing jkeiser, may be he knows what's going on.

Comment 7

16 years ago
However, it works properly if you make the link open in new window or a tab.

Comment 8

16 years ago
Ok, the bug is in version 3.516 of nsPresShell.cpp, where following code has
been added (I put the author on CC: list).

nsCOMPtr<nsIEventStateManager> esm;
if (NS_SUCCEEDED(mPresContext->GetEventStateManager(getter_AddRefs(esm))) && esm) {
  PRBool isSelectionWithFocus;
  esm->MoveFocusToCaret(PR_TRUE, &isSelectionWithFocus);
}

When the MoveFocusToCaret() call is commented out, anchors work as they should.
->aaronl.  This bug has been driving me crazy for the past week but I've been
too lazy to look into it.  It's very difficult to use jprof profiles or LXR.
Assignee: radha → aaronl
(Assignee)

Comment 10

16 years ago
Taking.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.0

Updated

16 years ago
Keywords: mozilla1.0+

Updated

16 years ago
Keywords: topembed+
As a note, commenting out the SelectRange() call just above that also fixes
things.  Perhaps we only want to SelectRange() when selectAnchor is true?

Comment 12

16 years ago
*** Bug 132037 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 13

16 years ago
Created attachment 75086 [details] [diff] [review]
Correctly uses startOffset and endOffset from dom range to get correct child

Ah, the nsIDOMRange gives me the parent, and I wasn't using the offset. The
parent happend to be the <body> tag in this case. Amazing we didn't catch this
in our testing, which was pretty thorough.

Updated

16 years ago
Keywords: nsbeta1 → nsbeta1+

Comment 14

16 years ago
Comment on attachment 75086 [details] [diff] [review]
Correctly uses startOffset and endOffset from dom range to get correct child

r=saari
Attachment #75086 - Flags: review+

Comment 15

16 years ago
Comment on attachment 75086 [details] [diff] [review]
Correctly uses startOffset and endOffset from dom range to get correct child

sr=hewitt
Attachment #75086 - Flags: superreview+
*** Bug 132321 has been marked as a duplicate of this bug. ***

Comment 17

16 years ago
Comment on attachment 75086 [details] [diff] [review]
Correctly uses startOffset and endOffset from dom range to get correct child

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #75086 - Flags: approval+
(Assignee)

Comment 18

16 years ago
fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
*** Bug 132455 has been marked as a duplicate of this bug. ***

Comment 20

16 years ago
This bug is half fixed :-(

When the page with anchor is /embedded/ in a frameset, it shows again.

For example, one of my site (french speaking one) :

http://frederic.bezies.free.fr/

On left side, click on "téléchargement", and then try to click on a link in the
page on the right side when it is loaded :-(

I am using :

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+) Gecko/20020320

Build ID : 2002032003 
Should this bug be reopened?

/be

Comment 22

16 years ago
It should be, yes ! :-(

What a pity this bug only show when page in embedded in a frameset !

The good news is that bug is no more /working/ in simple pages :-)

Comment 23

16 years ago
03-20 19:54 - marked fixed
 3 20 03    - build that someone felt didn't have the fix.

please reopen if you see this in a build dated 3-21 or later.

Comment 24

16 years ago
I will tell you tomorrow or saturday in a future nightly build.

Comment 25

16 years ago
Yhis bug is /dead/ ! Just verified a few seconds ago ! Very good thing !

I am using :

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+) Gecko/20020321

Thanks a lot !
*** Bug 132814 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 27

16 years ago
As the reporter, I am happy to say 'Works for me' using Build 2002032203
*** Bug 132875 has been marked as a duplicate of this bug. ***

Comment 29

16 years ago
*** Bug 133259 has been marked as a duplicate of this bug. ***

Comment 30

16 years ago
*** Bug 134021 has been marked as a duplicate of this bug. ***

Comment 31

16 years ago
VERIFIED Fixed with 200200328 builds
Status: RESOLVED → VERIFIED

Comment 32

16 years ago
Bug 159998 is said to have some relation with this bug or with its patches, is
it correct?
Who has free time to have a look of Bug 159998? It should belong to >P3.

Updated

10 years ago
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.