FF select dropdowns close prematurely

[emcniece]

Observed in FF 46.0, OSX El Capitan: select boxes have a lot of padding around them, and the select close event fires while the mouse is travelling between the open/close button and the dropdown choice list.

[emcniece]

Consider adding the class c-select to the selects: http://v4-alpha.getbootstrap.com/components/forms/#custom-forms

This does not solve the closing issue, but it will aid styling!

[emcniece]

Test: adding a select to the terminal area does not have this issue.

<select class="c-select form-control"><option>test</option><option>test</option><option>test</option><option>test</option><option>test</option></select>

Replicating the Device Select dropdown in the Terminal area doesn't have this problem either.

[kh90909]

Tracked down this issue to these lines in app.js:

  $('#sidebar').hover(function(){
    $('body').css('overflow', 'hidden');
  }, function(){
    $('body').css('overflow', 'auto')
  });

Commenting them out fixes the issue.

Looks like this code was intended to modify scrolling when when in the sidebar, but I don't see any difference in behavior with or without it. @emcniece do you remember what the intended function was? Are there any implications to deleting it?

Investigating this revealed another issue (#72: Sidebar doesn't scroll when it occupies the full width) which might be related to the non-functioning of this code.

[emcniece]

The #sidebar hover code was implemented to prevent child-element scrolling when hovering over the sidebar.

Without this code, expand all sidebar sections and reduce window height to the point where you can scroll both terminal and sidebar areas. You can safely scroll in the terminal area without affecting the sidebar scroll position, but scrolling in the sidebar past the top or bottom of its content will affect the terminal area.

This code was added to prevent unexpected behavior like this, but it may well be pointless. Let's remove it if necessary!

[kh90909]

If I'm following you correctly, I'm not sure this code was working as intended. Both with and without this on hover function, I found that scrolling past the limits of the sidebar would scroll the terminal content.

I see that the overflow: scroll is set on the html not body tag, but on hover is changing the class on body. Not sure if this is the issue.

Also, would moving the scrollbar from html to #content solve the scrolling past limits problem since the scrolling divs would be siblings not child and ancestor? On May 11, 2016 1:24 AM, "Eric McNiece" notifications@github.com wrote:

The #sidebar hover code was implemented to prevent child-element scrolling when hovering over the sidebar.

Without this code, expand all sidebar sections and reduce window height to the point where you can scroll both terminal and sidebar areas. You can safely scroll in the terminal area without affecting the sidebar scroll position, but scrolling in the sidebar past the top or bottom of its content will affect the terminal area.

This code was added to prevent unexpected behavior like this, but it may well be pointless. Let's remove it if necessary!

— You are receiving this because you commented.

Reply to this email directly or view it on GitHub https://github.com/kh90909/OakTerm/issues/66#issuecomment-218364889

[emcniece]

I also see identical behavior when this code is present and not - unsure if something has changed since implementation that causes this to be different, but I vaguely recall that in the "broken" state the sidebar scrolled the content area before it scrolled the terminal area. This is no longer the case.

The trick with scrolling the terminal separate from the sidebar is that all elements other than the terminal area are absolutely positioned. When a scroll event happens, the entire page (including terminal) scrolls while header, footer, and sidebar stay fixed.

Moving the scroll action to the #content div may disrupt natural page scroll. This is probably unnecessary for now, and it's much easier to remove this scroll-prevention code as 1) it doesn't do anything anymore, and 2) the resulting behavior is fine.

[kh90909]

This is probably unnecessary for now, and it's much easier to remove this scroll-prevention code

Okay, that's done in #73.