Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center....as per title. In case this might be a browser specific issue, I am seeing this in latest firefox 4.0 beta13 x64 nightlies under Win7 x64.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | admin_menu.toolbar-fixed.17.patch | 439 bytes | sun |
Comments
Comment #1
safetypinI'm using Chrome 12.0.742.30, and the admin_menu stays at the top of the window regardless of this option.
Comment #2
sunI'm not able to replicate this issue. Please make sure you also test whether this issue still exists when using the latest versions/development snapshots of affected modules. If that does not help, then also try to temporarily disable potentially conflicting modules that may interfere with this functionality.
In any case, please report back about the status of this issue. Thanks.
Comment #3
mediax CreditAttribution: mediax commentedSame thing just happened with the latest dev build.
I have my localhost testing server running fine, but my live site with the same imported database and modules,
admin menu does not respect "top of page" option.
Odd.
I tried to uninstall the module's data via drupal's backend, and re-active the module and set "top of page" option, but still scrolls.
I am also running fusion accelerator on both installs with the label and grid tabs shown which also scroll.
I will analyze the issue and possible fix.
Comment #4
andrewko CreditAttribution: andrewko commentedSame here. Latest dev version. Tried switching themes just in case, but no change.
Comment #5
andrewko CreditAttribution: andrewko commentedFound the problem.
The admin_menu_toolbar.css has the menu as fixed by default (line 28). The JS only sets the admin menu to fixed if the setting is set, there is no else statement. So either the css file needs to default to static or there needs to be an else statement in the js to $adminMenu.css('position', 'static'); (line 172 of admin_menu.js)
I hope that makes sense. I would assume the css file should be changed. (i.e. remove line 28 of admin_menu_toolbar.css).
Comment #6
deanflory CreditAttribution: deanflory commentedI too am experiencing this issue. By it staying at the top, it is impossible to use the scroll ball to scroll down the menus when there are lots of modules installed.
I'm using admin_menu-7.x-3.x-dev, from 2012-03-09.
Comment #7
andrewko CreditAttribution: andrewko commenteddeanflory. Just comment out line 28 from admin_menu_toolbar/admin_menu_toolbar.css and it should be fixed.
Comment #8
andrewko CreditAttribution: andrewko commenteddeleted. double post.
Comment #9
deanflory CreditAttribution: deanflory commentedThanks andrewko, had already done so.
Comment #10
ryantollefson CreditAttribution: ryantollefson commentedThanks.
position: fixed;has moved to line 31 as of 7.x-3.x-dev version from 5/1/2012Comment #11
andrewko CreditAttribution: andrewko commentedSetting this back to Active since we have a solution that needs to be checked in.
To any maintainer, line 31 (
position: fixed) in admin_menu_toolbar/admin_menu_toolbar.css should be deleted.Comment #12
ryantollefson CreditAttribution: ryantollefson commentedRelated to this - after commenting out line 31, I started getting a black bar to the right of the page (caused horizontal scrolling). I only tested in Chrome, so not sure if it would happen in other browsers or not. After changing line 32 (margin) to 0, this went away; however the menu entries did move slightly (I can still live with it, but it's not perfect).
Comment #13
sunah, this only pertains to admin_menu_toolbar.
I'm not exactly sure why this is hard-coded - perhaps there was a reason for doing so. Technically, position:fixed should still be applied via JS, so simply removing it from admin_menu_toolbar.css should still work.
Can anyone test?
Comment #14
andrewko CreditAttribution: andrewko commentedYes. Removing
position: fixedworks for me.Comment #15
ArrowRemoving
position: fixeddoes work, but I noticed something else that seems to have broken at the same time as this... Themargin-top: 20px !important;to adjust the margin no longer gets applied when using the overlay. Perhaps these issues are related.. something with the js perhaps?Comment #16
dimitriseng CreditAttribution: dimitriseng commentedUsing the latest dev version, removing
position: fixedfixes the issue. I don't get the issue mentioned in #15. However, this is not working when the Overlay module is enabled, in this case the toolbar stays at the top of the page irrespective of this setting.Comment #17
sunThanks for reporting, reviewing, and testing! Committed attached patch to all branches.
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.
Comment #18
DRippstein CreditAttribution: DRippstein commentedThis probably isn't even worth mentioning, but I just wasted an hour trying to debug this so here's the info for any other poor saps...
This update makes the toolbar incompatible with pages that have position:relative on the
<body>tag with a top margin/border.So if you find your admin toolbar is no longer positioned at the top after this update, it's probably because of this. Using position:relative on
<body>is very odd css and has very limited usefulness, and in this case, it's just not compatible with the update.The only use of that css is to prevent IE6/5 bugs on objects that are centering on the
<body>. I don't do that (this is what div containers are for), so removing that one css line cured this. Inadequete css's fault, the update is fine.Techie Nonsense on Why: This update removes position:fixed and makes position:absolute the default. Position:absolute items jump to the first position:relative parent (in this case,
<body>), defaulting to the<html>element if none is found. My site was thrown together on a rush job using a framework, and the position:relative on<body>came with it. When the body got pushed down because of margin/border, so did the toolbar.