Closed (fixed)
Project:
Nice Menus
Version:
6.x-2.x-dev
Component:
CSS
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
16 Apr 2007 at 12:39 UTC
Updated:
31 Jul 2008 at 04:46 UTC
Jump to comment: Most recent file
Comments
Comment #1
Pamulapati commentedCan anyone help me in sorting out this problem. I can see this issue only in I.E 7.0.
Thanks in Advance,
Chandu
Comment #2
add1sun commentedChanging status since there is no patch attached to this issue.
Comment #3
add1sun commentedUsing new components to organize.
Comment #4
onionweb commentedI can confirm this is a problem in IE7
Comment #5
add1sun commentedThis is happening in the current 5 dev version as well
Also, comment from another issue that really belongs in here: http://drupal.org/node/113965#comment-194649
Comment #6
Pamulapati commentedCan anyone help me in this issue. Do you need any further information(my working code/css) to review.
Thanks in advance,
Chandu
Comment #7
onionweb commentedI would guess that the issue has to do with the order the selectors are in.
IE is finicky that way. e.g.,
#menu-128 li might successfully point at its target in compliant browsers, but would have to be written as
LI#menu-128, in IE.
Comment #8
lonehorseend commentedObservations:
1) I forced Drupal to use the javascript for IE 7 just to see what would happen. It made the problem disappear, but it acted like it was drawing two menus on one another. Meaning that I selected one option in the menu list, then selected another one above or below it, it would wait until the second one had stopped drawing before the first one would disappear.
2) I notice that this problem happens with any menus that have more that one parent item. A Base > Level 1 menu is fine, but a Base > Level 1 > Level 2 or Base > Level 1 > Level 2 > Level 3 is not.
3) The first time the page loads, the menu works fine. However, when the user mouses of the menu a second (or more) time that a menu with mutiple levels is opened and only corrected when the mouse is positioned on a parent item in the next level. It's like IE is losing track of where it is as the mouse over event is happening.
Umm . . . I think I might have found a solution. Read here: http://murphy.cz/ie7-hover-ghosts-bug/, I'm going to write some style sheet modifications based on the article and see what happens.
Comment #9
skchow commentedI went through the link as given above (thank you lonehorseend for posting the link), and was able to rearrange the css in such a way that haslayout is no longer set for each ul item in the sub-menus. Unfortunately, after I got it to work for IE 7.0 with no more ghost submenus, it gave back some strange redraw errors in IE 6.0 . I have included the patch for those that are interested. Note: this patch includes the nice_menus_IE_third_level.patch . I also didn't make the needed changes for menu orientations besides my own, but the changes should be similar. In the end, I decided that using the javascript version of the code for both IE 6 and 7 will be best for my own application.
Comment #10
add1sun commentedmoving this to bug report. the patch no longer applies due to recent changes but even when I manually moved the position:absolute it did not work for me.
Comment #11
herb commentedFWIW I can confirm that with a clean install of 5.2, the "current" version of nice menus installed with the bluemarine theme seems to well with IE6, Firefox, and almost perfectly with IE7 with the exception this IE7 Hover Ghosts bug. The css patch didn't work for me either, and perhaps more importantly, the css "solution" shown at the link in post #8, doesn't seem to work with IE6 at all.
Since I expect a pure CSS solution that's cross browser compatible might not happen in the near future, could someone direct me to the "javascript version of the code for both IE 6 and 7" that others seem to be using? Or is there some other preferred approach at this time? - Thanks!
Comment #12
add1sun commentedAFAIK none of the fixes in this thread work. As for JS, IE6 is already using JS in the current code and since this problem seems intractable with CSS for the time-being we re just going to have to make both IE6 and 7 use the JS. I need to make my way back through the issue queue and I am traveling this week but hopefully we can try to make an official release for 5 very soon.
Comment #13
add1sun commentedOK, just so we can get some widespread testing on this I went ahead and committed the change to make IE7 use JS along with IE6. The 5.x-dev version should have this change in it when the next tarball rolls at noon GMT 10-10.
Comment #14
herb commentedThanks for the update. I just got the October 10, 2007 - 07:06 version, and while the md5_file hash is different, it seems that the packed files are identical to the earlier release. (and therefore the IE7 ghosts-bug still exists). Am I downloading the correct file, or is somewhere else I should look? Thanks
Comment #15
add1sun commentedHm, no that is the correct file and I verified that. I'm traveling today but I'll try to look at it more when I settle back down.
Comment #16
add1sun commentedThe latest download works fine for me in IE7. If you open a menu several items deep and then roll out, when you go back through the menu everything displays correctly - no ghosts. This works for both vertical and horizontal menus. You can see a temporary demo of it on my test site at http://test.rocktreesky.com/drupal5.
Comment #17
herb commentedThis is very curious to me.. Is it OK that this mornings dev version is the same as the previous dev version? I did a directory compare, and both versions were the same - The .module, .css are dated 8/15/2007 and the .js is dated 7/3/2007.
Nevertheless, I can see that it does work in the example link that you posted!! - I originally thought it was due to your use of the Garland theme, but changing the my test theme from Bluemarine to Garland changed nothing. I still get the ghosts in IE7.
I've compared the generated html and see a possible difference.
In my 5.2 garland, the first line after
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />is...<!--[if lt IE 7]>In your working Drupal 5 test, it's...
<!--[if IE]>Both versions load a fix-ie.css file at the end of the head using
<!--[if lt IE 7]>but your version seems to reload the jquery.js and drupal.js in the major block before the closing fix-ie.css while I my version doesn't seem to do that. (Meaning they aren't loaded??)
Would it make sense for me to try it using Drupal 5.1, or is there some other reason why the javascript load in the head might be different.
Thanks for your help!
Comment #18
herb commentedOK - I changed line 68 in nice_menus.module from:
drupal_set_html_head('<!--[if lt IE 7]>todrupal_set_html_head('<!--[if IE]>and now it loads in IE7, and the IE7 ghosts are busted! - I'm not sure how this didn't make it into my version but I'll use what I have until there is another official release. (Hopefully there are no other impacts that I'm unaware of...)
The only other minor issue that I have yet is probably a Z index issue where the menus tuck under gallery photo lists, but I'll fool with it to see if I can resolve it with CSS.
Thanks for your help!
Comment #19
joannemm commentedThis worked for me in IE 7.0 but I'm still seeing the hover ghost in IE 6. Is there something else I should be adding to make it work for IE 6?
The added code is saying
so it should be working.
thanks
Comment #20
joannemm commentedSorry - some text dropped out. I meant to say the added text is saying: "!--[if IE]" and not "!--[if lt IE 7]"
Comment #21
herb commentedOK - I just tried the "latest" which has the correct [if IE] and it seems to work with regards to hover ghosts in both IE 6 and IE7 for me.
It also seems to work well with both browsers if you use the garland theme.
However, it you use Bluemarine, and then view a gallery... ie ?q=image, in both IE6 and IE7 the drop-down menu disappears behind the gallery image. I haven't figured out the css issue yet.
Comment #22
add1sun commentedOK, well that is a separate issue. I've created a new one for the new z-index issue we seem to have with horizontal menus.
http://drupal.org/node/183924
Comment #23
(not verified) commentedComment #24
add1sun commentedReopening this issue so we can fix the IE7 CSS problem and remove the JS, pursuant to this issue: #269857: Remove JS from IE 7.
Comment #25
add1sun commentedchanging version....
Comment #26
jpstrikesback commentedglad to see this is on the burner again
Comment #27
add1sun commentedHm, so I ended up finding a weird little way of fixing this: simply changing from using "display" on the uls to "visibility". I thought visibility would do wacky things but it seems to be working for me in IE7, FF, Safari and Opera. Can folks please test this out and see if it is that simple.
Comment #28
add1sun commentedSwitching to new CSS component so others that can find CSS troubleshooting more easily.
Comment #29
add1sun commentedWent ahead and added this to all of the dev versions so I can actually get testers on this.
Comment #30
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.