Shape 5

Hiya.

Problem:

After using LiveSearch (while results window is still open, or after it's closed) hovering over a Flex Menu entry causes it to animate down (so far, so normal) but then it animates back *up* to above starting position.  ???

This behaviour persists until you refresh/navigate away from the page you started on.

Trying to investigate this one defeated me, I'm afraid - I didn't get anywhere with Firebug/Developer Tools, trying to follow what the live css was doing as things animated up and down.

I'm guessing there's a state/variable that the PHP/javascript is setting that conflicts ?  It's certainly beyond my skill level to debug.

Any help is welcome.

Site: http://87.106.124.7/joomla-new/ (http://87.106.124.7/joomla-new/)

--
kurai

Wow, that is very strange. I've been looking at it for a while now in firebug and nothing in regards to css changes with the menu at all when the live search closes, so I don't get how it's effecting it. Can you try changing the menu effect under the Menu tab in Vertex to see if it does the same thing on other effects?

Changed the menu animation styles, and it didn't have any effect.

Played around with it some more ...

The whole  <div id="subMenusContainer"> section is generated in an AJAX-y manner on the fly by s5_flex_menu.js and inserted as the last <div> on the page before the </body> closing tag.

The value for the menu sub-element's vertical position comes from a section in :-
 <div id="subMenusContainer">
       <div class="s5_sub_wrap[...]">
which has an inline of style="top: $px;"

Now - here's where it all gets a bit twisty & tricky  & *really* beyond my ability to fix ;)

In normal conditions the top: vertical position of the displayed submenu is correctly calculated as being below whatever the page-render calculates is the bottom edge of
 <div id="s5_menu_wrap">
      <ul id="s5_nav">
            <li>
and the whole <div id="subMenusContainer"> gets rendered there, over the rest of the page viewport, with a big z-index:

So far, so good ...

That "top: $px;" calculation seems to come from functions around about line 1026 of s5_flex_menu.js
There's a whole chunk of functions like :-

1026:   MenuMaticSubMenu.prototype.showSubMenuComplete=function()

   and

1051:   MenuMaticSubMenu.prototype.positionSubMenu=function()

    etc.

and that's where I run into terminal problems, as unfortunately it's way beyond my javascript skill level to determine exactly which part is doing it :-

*After* LiveSearch has been triggered this calculation seems to go haywire, and instead of the top: being properly taken from the absolute position in page of bottom edge of the <div id="s5_menu_wrap"> <ul id="s5_nav"> <li> block, including added offset height from any additional elements that get rendered above it in the page (e.g.<img id="s5_logo">) it, instead, uses only  the height of *just* the <li> block, ignoring additions from any previous page elements.
(the size of the <li> block can be changed by over-riding it's internal span heights with #s5_nav li .s5_level1_span2 { height:[$px;} in CSS)

Try changing that value in CSS, and you'll see that whatever value you put in there for height: will also get used as the value for top: that the submenu ends at after animation.

Hopefully that makes sense to you, and sorry for the excess of color tags - after I initially slapped all this into a post it was pretty much incomprehensible without some highlighting ;D

Hello,

Yes, I do see what you mean. The strange part is I can't replicate it locally, so would you be able to provide me with ftp access to debug this on your site?

In the meantime you can put the following into custom.css:

.s5_sub_wrap, .s5_sub_wrap_lower, .s5_sub_wrap_rtl, .s5_sub_wrap_lower_rtl {
top:138px !important;
}

that will at least give it a better look, but the second set of subs won't be lined up in the correct places.

Sure thing - sent as priv-msg

Nice job on the fix - thanks for the swift resolution.