Hi,

See the attached image, when secondary tabs are expanded on hover they are rendered behind other elements.

A trivial patch is on its way.

Thanks,
Antonio

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ao2’s picture

Status: Active » Needs review
Issue tags: ++patch
FileSize
21.78 KB
961 bytes

Patch attached, it can be applied with git am.

And an image to show the result.

Thanks,
Antonio

derjochenmeyer’s picture

Status: Needs review » Reviewed & tested by the community

Patch in #1 works. One line of CSS.

ericduran’s picture

I try to replicate this, but I can't seem to get the secondary tab to render behind any elements. How can I replicate it?

I added some new links just to test. This is what I see.

I know is just a single line of css, but it'll be nice to make sure we need it before adding it.

derjochenmeyer’s picture

It only happens on pages with .fieldset.titled elements like admin/content/node

rubik/core.css

.fieldset.titled {
    display: block;
    min-height: 30px;
    position: relative;
}

I ran into this bug reviewing "newsletter module" (http://drupal.org/project/newsletter). To reproduce install the newsletter module and visit admin/newsletters/templates.

fxarte’s picture

The patch works

melon’s picture

The patch is working for me as well, thank you Antonio for pointing this out.

When is this expected to be committed?
Thanks

mpotter’s picture

Patch works for me also and is critical when dealing with Media module style configuration. This *really* needs to get committed.

ao2’s picture

To project maintainers, you know, you can use git am to merge the change, this way the commit message and the authorship in the patch I generated with git format-patch are preserved.

Ciao,
Antonio

CoffeyMachine’s picture

Status: Reviewed & tested by the community » Fixed

This issue must have been fixed by another patch, because I cannot reproduce it on the dev branch of Rubik. I installed both the Media module and the Newsletter module and was unable to reproduce the issue on the pages mentioned above.

I'm also pretty confused by the content of the patch as it adds a z-index to the div.pager rule, which is for pagers. The screenshots show the drop down menus that are hit by the .secondary-tabs rule. .secondary-tabs needed the z-index to fix the issue, which it has now on the dev branch.

Regardless, this doesn't seem to be an issue anymore so I am changing the status to fixed. If I missed something please reopen it.

ao2’s picture

@CoffeyMachine the patch I attached does add the z-index to .secondary-tabs, it is just the diff header which does not reflect this. I think diff -p was meant for C-like code, it can get confused with other languages.

I cannot see the change which adds the z-index to .secondaty-tabs, can you paste a link to the commit?
I haven't tested yet if the patch is still needed, I'll let you know.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

TripleEmcoder’s picture

Patch works, and is still needed in the recent -dev.

shiroitatsu’s picture

Version: 7.x-4.0-beta6 » 7.x-4.0-beta7
Status: Closed (fixed) » Patch (to be ported)

Still not committed in beta7. Took me quite a while to see that reason for some links not appearing on secondary menu was cause by this little bugger as it very neatly hides the third+ menu items under the box below. Webform and Panels also suffer from this.

CoffeyMachine’s picture

Status: Patch (to be ported) » Fixed

Ah ok, I misunderstood the patch code. I'm still having trouble reproducing this issue, but I have gone ahead and committed the patch anyway.
Thank you!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

ao2’s picture

@CoffeyMachine, thanks for applying the patch, I can see it in commit 2289259.

Next time, please, consider using git am to apply my patches (which I prepare carefully and export with git format-patch), in doing so I will figure as the author in the git history (that's stronger than the "by ao2" in the short commit message), my patch also had a long commit message explaining the reason WHY the patch was needed, that has been stripped out as well.

Loosing attribution and see the work on composing an useful commit message wasted could discourage further contributions.

And when an issue is closed, I think that adding a link to the commitdiff would also improve the communication.

Just my 2c, thanks for your work on Rubik.

Regards,
Antonio