Using M15, build 2000041805, WinNT When a document contains an anchor <A NAME="whatever"> that is placed inside a <DT>, linking to it does not jump to that precise location. Instead, the link will send you to the beginning of the <DD> following the <DT> containing the link. At http://www.priss.org/pipes/eso.shtml, there is the linked word "blackpool" in the first paragraph. It links to "#blackpool", which is located further down the document inside a <DT>. Clicking on this link does not jump to the <DT> containing <A NAME="blackpool">, but instead jumps to the <DD> following this <DT>

I think the problem here is that the A element is empty, and this has to do with the interaction of the *quirks mode* inline layout algorithm and the scroll-to-anchor code. (The empty A element is given no height in quirks mode, because quirks-mode inline layout should not take its size into account when determining the height of the line.) Notice that when you scroll to #blackpool, you see the descender of the p because the baseline is exactly even with the top of the page. I think the real solution here is probably to have the scroll-to-anchor code go to the highest point in the line box (except are the line boxes still around?). However, it might fix this problem (but not others) to change the way the quirks mode line-layout works a little bit (I think it could be done easily, but I'd have to double-check). Confirming and retitling, although I think there might be a duplicate floating around somewhere.

Tom, I think this one may be yours.

Re-assigning this to myself. It isn't really an events problem. The code that scrolls to an anchor lives in the pres shell.

Accepting bug and setting target to M20...

This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

This is poor user experience. Do we really want to Future it? A really quick hack of a fix -- just scroll to 20px below where we do now -- would probably be better than not fixing it at all, no?

I like the idea of a hack-fix better than nothing. The problem with the way this currently renders is that the viewer may not know if s/he's landed in the right spot if no <DT> content is not exposed. With the hack-fix mentioned, browser display might still appear misaligned in some way, but I do feel that's a step better than leaving the site visitor confused. Of course, if the resources simply aren't available to allot any time to all bugs, then I guess we have to accept that...

I've made this testcase on a Windows 98 SE machine, where the bug doesn't manifests itself. Since the bug was filed for Windows NT, I cannot determine whether it is still valid, so I thought that I try to make a testcase for it, based on the problem description :)

Try removing the DOCTYPE and see if the testcase still behaves the same.

massive update for QA contact.

This is also a problem with a large image in a named anchor. We really need to find the line box.

copying my comments from bug 56285 (thanks david): I wanted to point out that currently (win build 2000101604) if you click on an anchor that links to an image above it, mozilla scrolls to the bottom edge of the image instead of the top of the image like NAV4 and IE5 do. I think that it is confusing that you have to scroll further up after clicking the anchor to see the actual image. ________________ I am adding a test case to demonstrate this problem.

Clicking on "Blackpool" (in the branch build) scrolls me down to exactly where I would expect - just so I can see the Blackpool text enclosed by the DT tags. Has this been fixed already?

It may work on that page, but it still fails on my own page. I use the "-//W3C//DTD HTML 4.0 Transitional//EN" doctype, and Mozilla is still scrolling to the baseline of the line containing the anchor. At http://www.wenet.net/~stephe/Wolves/index.html , try clicking on the four links near the top of the page. They should take you to the beginning of a paragraph, but Mozilla scrolls to the second line of the paragraph. Mozilla 102404 on NT4.

Adam, The attachment I created shows an example where the viewport is off. Mozilla should scroll to the top edge of image not the bottom edge of image when you click on the link to take you back up to the mozilla banner.

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

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

nominating 0.8. this is *ugly*

Well, assigning this to myself. I guess I'll try and get this reviewed and checked in, and I'll see if any reviewers can see any way to avoid making the PresShell depend on nsBlockFrame and nsLineBox.

I see what you're trying to do. I think I was looking at a similar bug over the holidays, where scrolling to empty targets would scroll one line too far down, so the line containing the target was just offscreen. I'll dig up the bug number. I don't like the dependancy you introduced. What about using nsILineIterator? Can you get the offset you need using the frames returned by the iterator without having to know about block frame and line box?

that's better. r=buster. waterson can sr.

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

sr=waterson

Fix checked in 2001-01-09 18:43 PST.

VERIFIED on Mac 01-18-15, Win 98 01-18-21.

Damn. This has regressed (win98 build 01-30-01). If you look at the second testcase (10-17-00) the viewport is off again. Also, here is a link to an image that the viewport is off on a site I work on (http://www.bsanet.org/bsj/2001/index.html#figure1). There are 3 links on this page that the viewport goes to the bottom of the image. :-(

Sorry for the SPAM. THe last build for 01-30 was a bad build because under 01-31-01-04 it works fine again.

Yup. Please don't use builds from the latest directory. You probably got an -MTEST build.