Tertiary menu items don't show up in Firefox 34 on Windows, OS X (& Linux on D6)

Hi,

i have the same issue in FF34.

I think the problem, isn't the z-index.

It's the opacity value in #admin-menu .dropdown li li.

After disabling, the menu the subsubmenus are visible.

Experiencing this on Firefox Developer Edition on Windows. Same as the screenshot provided in OP

same here. I am no css guru, but would be glad to provide a patch if anyone has found the fix for this.

There are two possibilities to solve this problem:
1. Change the "#admin-menu .dropdown li li" rule to be more specific
2. Remove the opacity property completely (I can't see the purpose of it anyway)

Suggested patch for the first option.
Note this patch is from version 7.x-3.0-rc4

I'm experiencing amost the same with FF 34.0 on Windoze.
It does not look exactly like the provided screenshot - in my case the tertiary menu does not show at all.
In my screenshot I tried to open the tertiary menu for blocks (german "Blöcke").

The patch provided in #5 worked for me.
I do not care, that it's loosing the menu's transparency, but some people might?

My css knowledge stops at filter and opacity, so I just fuddled around a bit.
Found setting the opacity to 1 in "#admin-menu .dropdown li li" (and changing nothing else) solved the problem for me.
First setting "background" is the fallback for the following "background-color" via rgba, isn't it?
And "filter" is IE8 thing to set opacity?

And is there some css style guide to put "background" and "background-color" in one line?
I think it looks ugly that way ;)

@gngn,

The admin menu is only shown in the back end (Usually only to developers). You can either remove the opacity / filter settings completely or you can change the background to rgba. The only browser not supporting rgba is IE8 and I'm guessing you aren't using it.

If you want to learn more about css I'm suggesting W3Schools

Yes, its about opacity tag. Thx

Eyal Shalev: 2. Remove the opacity property completely (I can't see the purpose of it anyway);

Resolved for: Firefox 34+ , Firefox Developer edition 34+ (currently 35.02a)

Add css to your theme / system theme:

#admin-menu .dropdown li li { 
   opacity: 1; //or initial
}

Cosmetic reroll of patch #5 (added one line break)

A better workaround is to add the following custom CSS to your theme:

#admin-menu .dropdown li li {
  opacity: 1;
  background-color: rgba(69, 69, 69, 0.88);
}

This does not remove the transparency.

And the corresponding code for the "Administration menu" module 6.x-1.8 is:

#admin-menu li li {
  opacity: 1;
  background-color: rgba(69, 69, 69, 0.88);
}

@roball,

There is no need to declare opacity: 1 if there was no opacity: 0.88 to override.

If you don't set a fallback a developer using IE8 (As if) will see no background on the menu items.

Yes, if there was no opacity: 0.88 from the module's CSS to override, then you don't need opacity: 1; in your own CSS. The workaround was intended without changing module code (thus it's just a workaround).

And, a developer won't use IE8 ;-)

I have observed the same issue in Firefox 34. and applying the changes proposed in the patch in #10 solved them for me.
It seems like a Firefox bug with list elements and opacity: whenever a li has opacity less than 1, its children are not displayed whatever their opacity is.

This also seems like a bug of FF34 to me. Thus changing this issue's Category and Title.

Right now, I'm trying to track down a problem that occurs for the editor of one of my pages, please see the screenshot (admin-menu-cutoff.png (35.05 KB)) attached. Is this the same problem as described in #1?

Patch in #10 worked for me too.

Patch #10 worked for me. Thanks for solving this mystery :) Hoping to see it merged

Helped me ideally patch of page https://www.drupal.org/node/2387761#comment-9408075
The patch is successfully operating at the same time there is much less change.

I'm still at FF 33.1 because I don't want to patch all of my sites CSS.
#10 works for me too, please include it in dev.

Patch #10 fixes the issue but really I think we should move away of "transparency effect".

--- admin_menu/admin_menu.css
+++ admin_menu/admin_menu.css
@@ -97,14 +97,8 @@ body.admin-menu {
 }
 #admin-menu .dropdown li li {
   background: #202020;
-  filter: Alpha(opacity=88);
-  opacity: 0.88;
   width: 160px; /* Required for Opera */
 }
-#admin-menu .dropdown li li li {
-  filter: Alpha(opacity=100);
-  opacity: 1;
-}

I think we should move away of "transparency effect"

I agree, admins could safely skip "bells and whistles" ;)

I also think priority should be raised because on latest FF the module is pretty unusable (especially for new users ignoring 2nd level menu existence).

I think we should move away of "transparency effect"

I also agree. This module is more about efficiency than eye candy and with the release of FF 34 it has become broken for FF users...

You can just write this to fix

#admin-menu .dropdown li li {
   float: none;
}

#10 worked for me. I had tried #28 but it failed after a minute.

--- admin_menu/admin_menu.css
+++ admin_menu/admin_menu.css
@@ -97,14 +97,8 @@ body.admin-menu {
}
#admin-menu .dropdown li li {
  background: #202020;
+ float: none;
  filter: Alpha(opacity=88);
  opacity: 0.88;
  width: 160px; /* Required for Opera */
}
#admin-menu .dropdown li li li {
  filter: Alpha(opacity=100);
  opacity: 1;
}

WORKS GREAT!

Note when viewing admin theme with Overlay the admin menu works fine with no patch or css override. Not sure if this will help in determining the best Patch to resolve the issue but I thought I'd point it out.

#10 worked so nice to see those options again. Was driving me nuts!

#10 work for me too. Thanks ofry.....

#10 worked fine for me. Thanks

So #30 worked but only on my homepage for the admin toolbar, when I go to any admin page, like Content, all the menus have that same issue. I cleared my admin toolbar cache and the theme cache, actually all cache, still have this issue on admin pages specifically, does anyone know a fix for this?

Did you apply the fix in your theme or in admin menu? With Overlay disabled, applying it in your theme will not fix the admin theme unless you fix both the front and the admin theme. That's why it's better to patch the module...

#28 works for me. Thanks!

Please merge #10 and push an new dev version. Thanks!

#10 is working for me on FF 34 for Mac.
#30 did not work for me. Couldn't see third-level items at all.

jeffschuler Specify which file did change.

If you can't get to the patch right away, I found the problem when away when I unchecked "Keep menu at top of page"

Nice call kappaluppa. That works for me.

For those who need more detail, navigate to admin/config/administration/admin_menu and uncheck "Keep menu at top of page"

For D7 sites I fixed the problem by unchecking "Use hardware acceleration when available" in Firefox settings: Advanced > General.

No luck with that on D6.

Thx TommyK, #43 works fine for me (FF34.0.5, OSX, D7 website.) Maybe a problem to report to Mozilla?

Thanks TommyK. #43 worked for me. Config : W8/FF34/D7.

I used #25 to fix this issue.

I happen to agree that the transparency adds nothing to the functionality. From a usability standpoint the menus are easier to read with that turned off.

Thanks everyone.

Patch in #10 worked for me too.

Hi would firefox 34 be updating their software (are they even aware of this bug?) or would I have to patch my drupal to fix this? Thanks.

#10 works for me. RTBC IMO. Thanks.

I, too, was having difficulty with the tertiary menu items displaying properly when using 7.x-3.0-rc4. I just installed and tested 7.x-3.x-dev in Firefox 34 on my Windows 7 machine. And we may still have a problem.

I find that the problem is fixed as long as the option "Keep menu at top of page" is not checked. When this option is checked, however, the tertiary menu items do not display properly.

Additionally, I find that the tertiary menus for only the first three "secondary" menu items display properly when "top of page" option is checked and the "shortcut" plugin option is also checked. When the "shortcut" plugin option is NOT checked (and the "top of page" option is still checked), the only portion of the tertiary menu items that display is that which would have been over the "shortcuts" bar (about the first 1.5 menu items of the tertiary menu). This last appears visually the same as the screenshot from dalin which he posted when first reported the problem in October and that of marcmueller which he posted 11 days ago.

I'm a site builder, not a programmer/developer. But hopefully this will point you "fixers" in the right direction. :)

Had the same issue. The patch from #10 works fine for me. Thanks!

#10 works for me too.
Thanks !

Both removing opacity (solutions from Comment #10 and #2387761: Level three menu items not autoexpanding with Firefox 34) as well as the simple float: none; from Comment #28 fixed this for me (I do not use overlay and could not care any less for the transparency effect).

Please commit any of these and be done with it.

Hi I'm administrator of many drupal site and it will be a big job to apply patch on every site.
I install https://addons.mozilla.org/en-US/firefox/addon/stylish/ add-on and add

#admin-menu .dropdown li li {
   float: none;
}

and it works for all of the sites.

My apologies to all. I am new to dealing with Drupal issues, and had assumed this had been committed to the latest Dev version, which had an update of today. I have read through the documentation I could find about dealing with issue queues, but am still having trouble determining when a fix to a problem has been committed. If anyone could direct me to the correct documentation on the subject, I would appreciate it.

Huh. First way - via git log. Because log messages usually contain issue number in queue.

Next. You can see which issue was recently set to "Fixed", etc...

@Sundevyl: see the handbook page on issue status: https://www.drupal.org/node/156119

This is one of the hottest issues I've ever seen and I vote to raise this issue priority.

I wonder what if Mozilla changes FF behavior again? Maybe it's a bug on their side?

Anyway, I tend to agree with those who think that opacity is redundant.

Thanks,
Konstantin

@joachim: thanks for the heads up. Helped a lot.

Code for Drupal 6:

Replace line:
#admin-menu li li { width: 160px; background: #202020; filter:Alpha(opacity=88); opacity: 0.88; }
With line:
#admin-menu li li { width: 160px; background: #202020; background-color: rgba(69,69,74, 0.88); }

Hi any hope this will be fixed in a future Firefox release? Anyone wanna assist? Thanks!

There's a lot of crosstalk on this thread, but patch #10 works for me, and AFAICT that's the one that's RTBC.

Could people posting suggested fixes please post proper patches rather than line-by-line descriptions of changes?

I'll have to try the patch. Unchecking "keep menu on top" works for Firefox, but Chrome then shows it at the bottom of the page and many of the items are cut off.

Tested #10 on the latest FF, Chrome, Opera and IE, moreover, on IE 8 compatibility mode. It works like a charm without noticeable changes in appearance. So I confirm RTBC.

Could people posting suggested fixes please post proper patches rather than line-by-line descriptions of changes?

#10 is already a patch, RTBC.

I asked Dave to take a look here and include that patch ASAP but still no answer.

Сorrect solution

@pvasili: your patch seems too invasive to me.
Rendeing issue is related to transparency, so removing it also brings better-reading menu items (a thing I already need on some of my themes).

Also, why did you change issue priority?
For FF users this is a show-stopper that makes the module pretty unusable (and make it seem a poor-quality one to newcomers).

Patch from #28. It's simply than others patches.
Patch from #10 is using rgba color which doesn't work in IE8 http://caniuse.com/#search=rgba.
See also Drupal Browser requirements https://www.drupal.org/node/61509.

Guys, are you kidding? Why don't you like #10? At least one reason?

> Could people posting suggested fixes please post proper patches rather than line-by-line descriptions of changes?

I should have also said: please explain why your patch is a better solution than previous ones.

This is not going to get fixed any time soon at this rate. Project maintainers need a clear consensus on which patch is the right fix.

I'm using Firefox 34.0.5 and #10 solution works perfectly for me, thx!

Guys, are you kidding? Why don't you like #10? At least one reason?

Patch from #10 is using rgba color which doesn't work in IE8 http://caniuse.com/#search=rgba.
See also Browser requirements https://www.drupal.org/node/61509.

This can be fixed quickly in the CMS by turning off " Keep menu at top of page" in : "/admin/config/administration/admin_menu"

There is a minor loss of functionality (the menu does not scroll with you anymore) but it doesn't really effect me, and fixes the issue without code. Try it as a short term fix until they new version is released.

xaffimarc

#10 works great for me. I'm managing over 20 sites, with this solution working for every one!

@Plazik, you're right, rgba is CSS3 feature which is not supported by IE8. We should support this legacy browser for D7 if the documentation says that or change requirements (It's almost impossible). So let's consider your solution as a potential candidate.

@xaffimarc, make sure you read comments above. Your solution was suggested at least two times. And it causes loss of functionality. We're choosing between correct solutions here.

@konstantin.komelin Comments appreciated

Patch #74 works for me too.

@Plazik: could you maybe edit the comment that patch is attached with your reasons given further down, so it's clearer?

> We should support this legacy browser for D7 if the documentation says that

It could be argued that since admin_menu is intended for developers, we're outside of the standard D7 browser support. And that no sane developer is using IE8 (or IE at all!).

But given that #74 works and is claimed to be compatible with IE8, it seems that it doesn't hurt to pick the fix that supports it.

Just tested #74 on FF, Chrome, Opera, IE11, IE8 compatibility mode. It works fine.

@joachim, I've edited my comment.

Many users use this module as a alternative for Toolbar module and not for developing.

So let's agree that patch from #74 is the recommended fix. It does not make sense to re-post other workarounds here, since we have a suggested fix.

Number 9 fixed it for me. Thank you so much for everyone's help!

For my D6.34 and Admin Menu 6.x-1.8, it was line 27 of /admin_menu/admin_menu.css.

Regards,
BigMike

Edit: Sorry I had no clue how many replies there were, just found the first suggestion that worked and moved on.

I can confirm that patch #74 worked for me

Confirmed to fix FF34 and FF35(beta). It also did NOT create any issues for me in IE10 or Google Chrome 38.

I've tested this in Firefox 34 and cannot reproduce this error. I know that several people have RTBC'd this but I'm hesitant to commit with it appearing to be not an issue with the current 7.x-3.x-dev code.

If this is no longer related to Firefox 34, or only happens under certain conditions, then we need the issue summary updated urgently.

I am still getting this problem on Firefox 34 on OS X 10.6, on all of my Drupal sites, both live and dev environments.

I sure hope this fix gets into a release, because without a patch, admin_menu is basically broken for firefox users

Ok, so this is reproduce-able for Firefox 34 on Mac, not Linux. An issue summary specifying browser version and operating system would have been significantly more helpful for maintainers.

Changing the title to reflect the problem has been reported to occur on Windows and OS X operating systems. Linux has been reported to be *not* affected.

Patch #74 works fine for me in FF34.0.5

1-line patch #74 works for me too, FF34.0.5 on Win7-x64.

May I be so bold as to set this to RTBC? I am using #10 in production, but several people now have reported #74 to work correctly. The confusion reported by Dave Reid in #89 has been cleared up to.

Fucking Firefox... I told every customer to user Firefox. Now I had to patch a zillion drupal sites... :-/

Reviewed +1 #74. I prefer #74 over #10

I can also confirm that my issue was related to the Windows OS and FF 34. It is also an issue on Windows with FF 35 (beta channel). #74 fixed both for me.

#10 works fine. Nightmare lost all morning trying to figure out this after FF update..

Updated issue summary so that it reflects initial problem and our progress.

It seems that nobody has noticed it but this is also a bug on Firefox Developer Edition. And yes, #10 fix it on FFDeEd too.

@altrugon It just means that you didn't read comments above, i.e. #2 and #86. But thanks, I added FF DevEd to the issue summary.

Does it need another confirmation? #74 solves it for FF 34.0.5 on MAC OS.
Thanks to all taking care here!

OK. Patch #74 solves my problem too :) Windows 8.1, Firefox 34.0.5

#74 is RTBC for me.

Meanwhile I added Stylish plugin to my FF (see #55) to fix all of my sites.

Vote for Patch # 74 written based on # 28 and # 30.
Patch # 74 works fine in Firefox 34.0, Chrome 39.0, IE 8.0-11.0, Opera 26.0

Ok committed #74 to 8.x-3.x and 7.x-3.x. According to #2389227: Correctly display tertiary menu list items in Firefox 34+ Drupal 6 this would also need fixing for Drupal 6. Let's find the appropriate backport patch here.

Thank you for committing the fix to 7.x-3.x and releasing 7.x-3.0-rc5. Working perfectly.

Attached is the backported patch against the 6.x-1.x branch.

Hi,

The patch #115 in works perfectly for me on FF 34.0

Cheers

Tom

#115 solved the problem for me in Drupal 6, too.

This was not reproducible on Linux with Firefox 34. Unless you're confirming that it was?

It was an issue on my linux box.

Drupal 6 - Firefox 34 - Linux - happens.

Committed #115 to 6.x-1.x, but we still need a patch for 6.x-3.x.

Thanks for committing to 6.x-1.x. I know there are only 2 commits since 6.x-1.8, but do you consider releasing 6.x-1.9 anyway? The last commit is quite important, and 6.x-1.8 has already been released back in 2011, so I think it should be no problem to roll out another release soon.

Bump, it would be good to get a new release with this fix in as it's a biggie.

I can confirm that its still an issue in the new FF 35.0.1 - thx for the patch

Thanks, the commits on 7.x-3.x and 6.x-1.x solve the issue for Firefox v.35.x also.

Can confirm #115 fixes the issue on D6 and FF35.

@129: This patch has already been committed, so there is no more need for confirmations.

...maybe we need to change status to Fixed.

maybe we need to change status to Fixed.

No, because (see #123):

we still need a patch for 6.x-3.x.

@130: It's not fixed on the current recommended version for D6.

It is fixed in the admin_menu-6.x-1.x-dev release from Jan 24, 2015 https://www.drupal.org/node/251566
But, the dev release is not shown on the project page. Either showing the dev release on the project page or having a new 6.x-1.x tagged release would help.

New 6.x-1.9 release is out.

Thank you Dave, that will help a lot of people. Just updated to 6.x-1.9 and can confirm it's working fine.

Just a note to say that this bug, which was also apparent in the 7.x-3.x branch on Firefox 35 (but maybe previous versions also) has been fixed in 7.x-3.x-dev by 2015-Feb-21.

@mshepherd: This bug has already been fixed with the releases of 7.x-3.0-rc5 and 6.x-1.9. It just needs to be fixed also in 6.x-3.x-dev, thus this issue's status is still at "Patch (to be ported)".

@roball Yep, I said it was fixed :-)
Thanks.

Since the issue is already solved, so I am going to mark the issue as fixed.

However, if anyone is still facing the issue, please to re-open the issue.

I have also changed it to D7 because D6 is EOL (End-of-life).