Smallscreen accordion breaks AJAX

acrollet gave me a good idea to try to run Drupal.behaviors() after adding the new Dom elements, which might solve this issue. I'll look into it and see if that does it.

in many many cases dropdowns made for desktop versions have stuff that is impossible to fit in either a
or an accordion, so there had to be a way to sanitize the input anyway, on the other hand even if there was a way to use the same object for all the three it could be very much resource-consuming to alter the object and revert and so on (revert as in for example when switching from portrait to landscape on a tablet) so all in all it was not possible nor efficient.

I feel you about needing to clean up the UL structures for conversion to select lists. However, with the advent of responsive layouts, I felt that stacking of columns and having a mega menu that requires scrolling down the page is not an invalid method for navigation, on the contrary, it is one that works fairly well with the accordion functionality.

Aside from what you've stated above, why couldn't we just add/remove the sf-accordion class from the ul, and do the rest (eg hiding of elements, changing / stacking layouts) in CSS? This doesn't seem that it would be too resource intensive, but of course, I could be missing something.

if Drupal Behaviors didn't fix the problem setup an example and put it online so I can check, thanks!

Unfortunately, Drupal.attachBehaviors did not fix the problem. There is a fundamental issue with using javascript clone() on a view that has ajax enabled, because of the DOM ID used by views, created based on an md5 hash. Clicking the ajax pager of the cloned object still tries to update the view in the original menu, not the one in the cloned accordion menu.

Also, fwiw, switching to javascript clone(true) doesn't solve this problem either, as it suffers from exactly the same issue -- the original DOM object is updated, not the clone.

I've setup a testing site at https://dev-responsive-minipanels.gotpantheon.com, with the following modules:

 ctools 7.x-1.4        
 menu_minipanels 7.x-2.x-dev                  
 panels  7.x-3.4        
 superfish  7.x-1.9+29-dev 
 views 7.x-3.7        
 responsive_bartik 7.x-1.0-beta2

I've attached the patch of what I've currently written, and is currently being used on https://dev-responsive-minipanels.gotpantheon.com.

So its clear, here is how to see the error:

1. Reduce your browser window size down to around 400 pixels wide.
2. Expand the menu, and click the menu minipanels link, note that you are seeing results 1 through 5 of the view.
3. Then click the view pager "next" link, and wait for it to finish loading.
4. Note that the view disappears entirely.
5. Expand your browser window up to > 900 pixels wide and hover the "Menu MiniPanels" link in the main menu.
6. Note that you are now on "page two" of the view, showing results 6 through 10.

I ran with the idea of not cloning the menus, and have forked the Superfish-For-Drupal on github, to see what would happen.

https://github.com/jameswilson/Superfish-for-Drupal/commit/60c2e89e5112d...

Long story short, i got it partially working, and ajax views behave properly (yay!) however (ohnoes!) a couple other issues have popped up as a result of not cloning:

• On mobile, both the regular sfHover classes and fullscreen superfish menu hover events still trigger IN ADDITION TO the accordion sf-expanded click events. I was thinking maybe to just do a search and replace all instances of sf-expanded with sfHover on the <li> elements ( except for where that class is used to toggle visibility of the entire menu on the <ul>).
• Sizing up from a small size to a larger size, the *widths* of the superfish menu items need to be recalculated and placed inline). This maybe hints at a larger issue that would be difficult to work around, so maybe I'm thinking I should store the inline styles on the <li> elements in a data object, so that I can swap them out, similar to what I'm doing on the <ul>.

Thanks for having a look!

Just to be clear the changes i was working on in #9 are NOT what is being used on the demo site, which still contains the clean original github master branch, and the module patch on #7.

a) the main <ul> (the one that gets a menu-minipanel-panel class) to have an ID,

Easy, we can use the mini_panel's machine name and run it through drupal_html_id in our module (patch in next comment).

b) the very same element to also have a sf-smallscreen-move class, well from which you can guess what the solution is!

Actually, can you spell it out? what does this do? I'm not familiar with what this class does, and am tied up in other things right now.

You can implement a preprocess function in superfish module to add the needed class like this:

function superfish_preprocess_menu_minipanel(&$vars) {
  $vars['classes_array'][] = drupal_html_class('sf-smallscreen-move');
}

Patch for comment #13 item A to add unique ID (Note this is a patch for menu_minipanels module, not superfish). I updated the comment #13 with some more info, please re-read if you already have.

Can you let me know how this goes?

I can expedite getting this patch into menu minipanels 7.x-2.x-dev asap, it almost makes sense to do anyway.

Not sure we should be adding a new dependency to the module just to solve this sufficiently "edge" case. Damien?

What if we add the weight part of the patch in #19, and then add a note to Readme and Project in "Known Issues" section (or the like) referencing this issue and how to resolve it using behavior weights module?

Thanks for #23, but I don't understand your position entirely. In your opinion, is this something that would demand the extra module dependency? or could we try this as a partial patch + documentation issue as I suggest?