38280 - link to empty named anchor puts baseline at top of viewport

Status: RESOLVED FIXED

(Core :: Layout, defect, P2)

Description

[Kevin Cook]

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>

Comment 1

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

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.

Comment 2

[rickg]

Tom, I think this one may be yours.

Comment 3

[Nisheeth Ranjan]

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

Comment 4

[Nisheeth Ranjan]

Accepting bug and setting target to M20...

Comment 5

[Nisheeth Ranjan]

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. 

Comment 6

[Hixie (not reading bugmail)]

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?

Comment 7

[Kevin Cook]

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...

Comment 8

[slipszi]

Attachment: Testcase (see my comments about it)

Comment 9

[slipszi]

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 :)

Comment 10

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

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

Comment 11

[gerardok]

massive update for QA contact.

Comment 12

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

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

Comment 13

[James Lariviere]

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.

Comment 14

[James Lariviere]

Attachment: test case -- link to image in anchor that is above it

Comment 15

[Adam Lock]

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?

Comment 16

[Stephen Moehle]

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.

Comment 17

[James Lariviere]

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.

Comment 18

[Hixie (not reading bugmail)]

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

Comment 19

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

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

Comment 20

[Judson Valeski]

nominating 0.8. this is *ugly*

Comment 21

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

Attachment: attempted hack fix that doesn't even work (hopefully I'll have time to debug later...)

Comment 22

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

Attachment: version that works for text but not image

Comment 23

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

Attachment: a working patch (although still a hack)

Comment 24

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

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.

Comment 25

[buster]

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?

Comment 26

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

Attachment: patch using nsILineIterator

Comment 27

[buster]

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

Comment 28

[buster]

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

Comment 29

[Chris Waterson]

sr=waterson

Comment 30

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

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

Comment 31

[Loco]

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

Comment 32

[James Lariviere]

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. :-(

Comment 33

[James Lariviere]

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

Comment 34

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

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