162369 - scrolling to named anchor doesn't consider areas covered by fixed positioned elements

Status: NEW

(Core :: Layout, defect)

Description

[Asa Dotzler [:asa]]

a named anchor is not scrolled to the correct position.

In my weblog I have a fixed position div that acts as a banner at the top of the
page. I also have a primary content div that scrolls behind the fixed position
banner div. I set top: 6em; on the primary content div so that the top blog
entry displays lower in the viewport than the fixed position banner div. 
When I click on a link to a named anchor the page scrolls the anchor to the top
of the viewport which is behind the fixed position banner div. It should scroll
the anchor to the "top" which I've specified as 6em lower than the top of the
viewport.

Hixie said this might be a Mozilla bug. It might also be that I don't know what
I'm doing or that my expectations are broken and not Mozilla's layout. There is
no good way to test this on winIE since winIE doesn't do fixed position. Opera
and MacIE display the same behavior as Mozilla. 

Tested with latest trunk and latest 1.1 branch builds on windows, linux and mac.

Comment 1

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

Any possible way of fixing this seems like it would be pretty ugly.  It seems
that what you really want is to have the scrollbar be on something that is the
size of the visible area of the body.  However, that's hard without frames.

(Yet again, back to the question of why the HTML folks waited until 2002 to come
up with a good frames design rather than doing better frames in 1997...)

Comment 2

[Boris Zbarsky [:bzbarsky]]

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

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[Boris Zbarsky [:bzbarsky]]

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

Comment 5

[Patrick Godeau]

Attachment: test case for some other bug

This example shows that selecting a named anchor does not scroll to the right
position. All contents between <a> and </a> should be seen.

Comment 6

[habere-et-dispertire]

i've found the same problem with fragment identifiers in w3 specifications.
clear your cache and try:

http://www.w3.org/TR/REC-CSS2/tables.html#propdef-border-collapse

mozilla bounces around (five times?) and settles in the wrong location. once
loaded, refresh and it will hop to the correct spot.

(tested in 1.6 and 1.8a nightly 2004/04/22. opera 7.23 copes fine.)

Comment 7

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

comment 6 is unrelated to this bug.

Comment 8

[habere-et-dispertire]

(i don't post comments/bugs often, but i like to get them right and not post
duplicates.) this looked like the closest match and the testcase in comment 5
does not involve fixed positioning, so i took the summary's parentheses to mean
optional.

Comment 9

[Jerry Baker]

Is there a work-around to allow the use of the spacebar or page down for scrolling on pages with fixed position elements?

Comment 12

[Karl Dubost💡 :karlcow]

An example of this issue.
https://webcompat.com/issues/3516

Comment 13

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 14

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 7 duplicates.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 18

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 19

[Thomas Wisniewski [:twisniewski]]

The mozillazine link is no longer up, but the header is still obscured at https://webcompat.com/issues/3516. Let's move that to a corresponding webcompat knowledge-base bug.