Closed Bug 130447 Opened 22 years ago Closed 22 years ago

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

Categories

(Core :: DOM: Navigation, defect, P1)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: acraigwest, Assigned: aaronlev)

References

(
URL
)

Details

(Keywords: regression, topembed+)

Attachments

(1 file)

Correctly uses startOffset and endOffset from dom range to get correct child
1.87 KB, patch
saari
: review+
hewitt
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
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
*** Bug 130449 has been marked as a duplicate of this bug. ***
*** Bug 130555 has been marked as a duplicate of this bug. ***
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.
However, it works properly if you make the link open in new window or a tab.
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
Taking.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.0
Keywords: mozilla1.0+
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?
*** Bug 132037 has been marked as a duplicate of this bug. ***
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.
Keywords: nsbeta1 → nsbeta1+
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 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 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+
fixed
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 132455 has been marked as a duplicate of this bug. ***
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
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 :-)
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.
I will tell you tomorrow or saturday in a future nightly build.
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. ***
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. ***
*** Bug 133259 has been marked as a duplicate of this bug. ***
*** Bug 134021 has been marked as a duplicate of this bug. ***
VERIFIED Fixed with 200200328 builds
Status: RESOLVED → VERIFIED
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.
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.

Attachment

General

Creator:
Created:
Updated:
Size: