scrolling to named anchor doesn't consider areas covered by fixed positioned elements
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: asa, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [IGNORE COMMENTS 5 THROUGH 8] )
Attachments
(1 obsolete file)
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.
Reporter | ||
Updated•22 years ago
|
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•22 years ago
|
||
*** Bug 171404 has been marked as a duplicate of this bug. ***
Comment 3•22 years ago
|
||
*** Bug 171036 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Comment 4•21 years ago
|
||
*** Bug 206677 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Comment 5•21 years ago
|
||
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 hidden (off-topic) |
comment 6 is unrelated to this bug.
Comment 8•21 years ago
|
||
(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•19 years ago
|
||
Is there a work-around to allow the use of the spacebar or page down for scrolling on pages with fixed position elements?
Updated•15 years ago
|
Comment 12•8 years ago
|
||
An example of this issue. https://webcompat.com/issues/3516
Comment 13•5 years ago
|
||
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.
Comment 14•5 years ago
|
||
See bug 1547409. Migrating whiteboard priority tags to program flags.
Updated•5 years ago
|
Updated•2 years ago
|
Comment 17•2 years ago
|
||
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•2 years ago
|
||
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•2 months ago
•
|
||
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.
Updated•2 months ago
|
Updated•2 months ago
|
Comment 20•20 days ago
|
||
The spec and the implementation both uses ScrollIntoView behavior. (Element::ScrollIntoView is a mere wrapper on top of PresShell::ScrollContentIntoView.)
Meaning one would expect the same behavior between two, but that only applies to Gecko but not on Blink. (Try opening http://httpwg.org/specs/rfc7231.html#safe.methods and run document.getElementById("safe.methods").scrollIntoView()
).
Can't immediately see how Blink scrolls to anchor in the code though.
Comment 21•19 days ago
|
||
(In reply to Thomas Wisniewski [:twisniewski] from comment #19)
The mozillazine link is no longer up
archive.org has it, fwiw:
https://web.archive.org/web/20020812013954/http://www.mozillazine.org/weblogs/asa/2002_08_01_asadot_archive.html#79906274
(Snapshot taken on 2002-08-12, the same day this bug was filed!)
Firefox and Chrome scroll to the same initial position when loading that URL, with this being the first text that's visible:
Matt Judy, world-renowned Cocoa developer and celebrity hacker extraordinaire, has this to say of XUL:
The anchor (an empty a
element) is in-the-viewport but covered up by the header. Anyway: good news that we're interoperable in that case at least.
Description
•