Closed
Bug 38280
Opened 25 years ago
Closed 24 years ago
link to empty named anchor puts baseline at top of viewport
Categories
(Core :: Layout, defect, P2)
Core
Layout
Tracking
()
RESOLVED
FIXED
mozilla0.8
People
(Reporter: kcook, Assigned: dbaron)
References
()
Details
(Keywords: testcase)
Attachments
(6 files)
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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>
Assignee | ||
Comment 1•25 years ago
|
||
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: link to anchor within <DT> jumps to following <DD> instead → link to empty named anchor puts baseline at top of viewport
Comment 3•25 years ago
|
||
Re-assigning this to myself. It isn't really an events problem. The code that
scrolls to an anchor lives in the pres shell.
Assignee: joki → nisheeth
Comment 4•25 years ago
|
||
Accepting bug and setting target to M20...
Status: NEW → ASSIGNED
Target Milestone: --- → M20
Comment 5•25 years ago
|
||
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.
Updated•25 years ago
|
Target Milestone: M20 → Future
Comment 6•24 years ago
|
||
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?
Reporter | ||
Comment 7•24 years ago
|
||
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 :)
Assignee | ||
Comment 10•24 years ago
|
||
Try removing the DOCTYPE and see if the testcase still behaves the same.
Assignee | ||
Comment 12•24 years ago
|
||
This is also a problem with a large image in a named anchor. We really need to
find the line box.
Comment 13•24 years ago
|
||
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•24 years ago
|
||
Comment 15•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
*** Bug 62930 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 19•24 years ago
|
||
*** Bug 62978 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 21•24 years ago
|
||
Assignee | ||
Comment 22•24 years ago
|
||
Assignee | ||
Comment 23•24 years ago
|
||
Assignee | ||
Comment 24•24 years ago
|
||
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.
Assignee: nisheeth → dbaron
Status: ASSIGNED → NEW
Component: HTML Element → Layout
OS: Windows NT → All
Priority: P3 → P2
Hardware: PC → All
Target Milestone: Future → mozilla0.8
Comment 25•24 years ago
|
||
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?
Assignee | ||
Comment 26•24 years ago
|
||
Comment 27•24 years ago
|
||
that's better. r=buster. waterson can sr.
Comment 28•24 years ago
|
||
*** Bug 61224 has been marked as a duplicate of this bug. ***
Comment 29•24 years ago
|
||
sr=waterson
Assignee | ||
Comment 30•24 years ago
|
||
Fix checked in 2001-01-09 18:43 PST.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 31•24 years ago
|
||
VERIFIED on Mac 01-18-15, Win 98 01-18-21.
Comment 32•24 years ago
|
||
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. :-(
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 33•24 years ago
|
||
Sorry for the SPAM. THe last build for 01-30 was a bad build because under
01-31-01-04 it works fine again.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 34•24 years ago
|
||
Yup. Please don't use builds from the latest directory. You probably got an
-MTEST build.
Updated•24 years ago
|
Keywords: mozilla0.8
You need to log in
before you can comment on or make changes to this bug.
Description
•