UI: Ctools Dropdown appears partially hidden

That's a really annoying issue.
Need to work on it, probably will also need to apply the changes for D8.

Please read the link about "Descriptions of the priority and status values" before changing them. Thanks.

I think this is actually a major issue.

I am running into it in Linux-Ubuntu / Firefox when editing a panels page (I'm not sure what browser/OS the original reporter of this issue is using, but I can confirm it happens on this combination). In the Panels Page UI, the bottom-most item in the Content screen cannot be removed, because the pop-up menu that you get when you click on the wheel has the "Remove" option way down at the bottom, and it is scrolled off the screen and cannot be selected.

I could attach another screen shot, but it looks just like the one in the original report.

To reproduce:

a) Create a Panels page, going through the entire wizard interface.
b) If you are not already on the (single) variant's Content vertical tab, navigate to that.
c) Add a pane to the bottom-most content region shown on the screen, such as a "New custom content" saying "hello world".
d) Attempt to remove this newly-added pane by clicking on the wheel. The Remove menu item is hidden and I have not found a way to scroll in Linux-Ubuntu / Firefox to make it display, aside from hacks like using Firebug to make the menu always visible or something like that.
e) If you cannot reproduce with these steps, make your browser window shorter and you'll see it happen.

Since I don't know of any other way to remove a content item I've added to the panels page, I think this is a "major" bug rather than "minor".

As another note... When I open the menu, I notice that my overall page gets taller. However, the way it does this is that what I was looking at previously stays visible and the new part is hidden below, and I would have to scroll the main page down to see the bottom of the menu (this is also illustrated in the screen shot above). However, if I move my mouse over there to scroll the page, the menu goes away as well as the extra page height.

So somehow in the JS/CSS, what needs to happen is that if the menu would go below the bottom of the page, it needs to be shifted upwards. Or else the page needs to be scrolled down so that the entire menu div is visible. Too bad I'm not much of a CSS/JS whiz... I'm not sure how to fix it?

As a workaround the pane can be moved up and then removed, which is crappy but functional.

Ultimately, my dropdown .js is pretty crappy and I don't actually have the chops to be able to fix it. :(

True, that is a viable workaround that doesn't involve Firebug. :) My brain usually works in the "delete the old one first, then add the new one" way, but yes you can add the replacement first, move it up if necessary, then go back and delete the original item you were trying to remove.

It sounds like maybe ctools needs to recruit someone with more JS prowess than either of us to fix this?

Opinions/feedback required... I've been playing around with the options trying to get it working while also providing a good UI experience. Each option I try seems to have it's own set of issues/drawbacks. Solutions below, ordered from best to worst as I see it...

1) Don't make the menu disappear on mouse-out
This is the most feasible option I can think of right now which doesn't involve altering too much.
On clicking the clog the menu appears, but it doesn't disappear on mouse-out. This way the user can use the browser scroll-bar to bring the hidden bit of the menu into view. To hide the menu they will need to click the cog again. Could also make it disappear with an off-menu click (like a lightbox).

Benefits include working with tablet & mobile (no hover state), and not needing to target CSS styles in external files (Panels).

2) Auto-scroll the page down to reveal the bottom of the menu
You click the menu and as it expands and the browser window auto-scrolls down to reveal the bit would have been cut off. Problem is that the mouse pointer automatically goes into the mouse-out area as the page scrolls. We could get around this by shifting the drop-down menu to the right a little bit so that the menu aligns directly under the cog and mouse pointer stays in the mouse-over zone. Suppose we could get around this by only scrolling down if the menu isn't going to the get hidden at the top of the screen, but we could end up with the 'reversal-of-problem' issue mentioned next.

3) Move menu up to reveal hidden menu bit
By shifting the drop-down menu up to reveal the hidden bit you could potentially cut off the top while making the bottom visible. Probably not an issue when the drop-down is short/standard in length, but if you have a long menu, eg. with a long list of 'visibility rules' then it would cause problems.

Problem with this approach is that it will probably need to target CSS which is Panels specific (included in a Panels module CSS file). This is obviously not CSS you want to be targeting from the cTools 'dropdown.js' file. BTW where else is the dropdown.js file used besides in Panels?

-----------

There I was thinking this would be a really quick issue to sort out ;)

A JS script was added on ctools/js/dropdown.js.

The script calculate the scroll and apply.

Thank you for your contribution to this issue.

There are some comments below on the patch code, but overall it would be good if you could, in the code or here, address the points @justinchev made in #7 and in particular what choices you made.

1. +++ b/js/dropdown.js
   @@ -60,6 +60,13 @@
   +            scrollHeight = $("."+id+" ul li .last").prevObject[0].scrollingElement.scrollHeight;
   

   JS usage recommendations suggest using 'find()' rather than space-separated lists, and also recommend not repeating JS (i.e. extract: $().*.scrollingElement).

   I would wish to be very sure that variable 'id' contained a syntactically valid css name.

   Finally that code appears to assume that the scrollHeight et al calculation succeeds; I think at very least the length of prevObject[0] should be checked to be >0. Not sure if same is true of scrollingElement, but it probably is.

2. +++ b/js/dropdown.js
   @@ -60,6 +60,13 @@
   +            margin = 40;
   

   Where is the magic number 40 coming from? At very least a comment is needed on this to say so (if for example it is a 'comfortable for a person to read gap').

3. +++ b/js/dropdown.js
   @@ -60,6 +60,13 @@
   +            // example
   

   example... of what?

4. +++ b/js/dropdown.js
   @@ -60,6 +60,13 @@
   +            $(".ctools-dropdown-2 ul li .last").prevObject[0].scrollingElement.scrollTop = maxScrollPosition;
   

   Many of same comments on scrollHeight apply here as well, perhaps even more so because you're changing a value.