Closed bachrach44 closed 4 years ago
Another temporary workaround is to reduce the font size (Control & the minus key on Windows. Options & the minus key on Mac.)
Thanks for the report. I am so used to scrolling withe gestures (on a trackpad) or scroll wheel (on a mouse), that I didn't realize clicking the side panel scroll bar would do this.
What I am seeing (on Mac/Chome) is that when you try to use the scroll bar while a commentary is expanded, if you release the mouse ("mouseup") while still hovering over the scroll bar, the shrinking doesn't trigger, but if you mouse has moved outside of the scroll bar when you release the click it will. Let me know if you're seeing differently on Windows. This can be another workaround and maybe a hit to how to actually fix.
On Fri, Mar 7, 2014 at 4:06 AM, Lev Eliezer Israel <notifications@github.com
wrote:
Another temporary workaround is to reduce the font size (Control & the minus key on Windows. Options & the minus key on Mac.)
Reply to this email directly or view it on GitHubhttps://github.com/blockspeiser/Sefaria-Project/issues/78#issuecomment-37018423 .
Well, I've just learned something about myself - when I scroll down I usually pull slightly to the right, and when I scroll up I pull to the left. Go figure.
Anyway, I can confirm that I see the same behavior in WIndows that you saw on the Mac.
This works, so it's probably a good starting point at least. It selects slimScrollBar and slimScrollDiv, which are both necessary. The if
statement avoids the ones from commentaryViewPort
, which should obviously trigger the close.
$('[class^=slimScroll]').on('click', function(e){
if ( $(e.target).is('[class^=slimScroll]') ){
e.stopImmediatePropagation();
}
});
You could just move the if statement to the window.click binding, and it should do the same thing.
It still closes if you pull to the left, instead of the right, though, but I'm not sure why yet, so lefties beware.
Thanks for working on this and submitting and fix.
I've just been playing around with it and unfortunately I'm not see any change in behavior (on Mac/Chrome). Pulling to right and left still triggers the shrink, though sticking on the scroll bar doesn't. I've tried attaching the event to window and using e.stopPropagation() as well and am not seeing any difference. I can see that the event is being triggered the the inner condition met, but for me it's still not preventing the shrink.
Huh. Just pasting that into my Chrome (Windows 7) js console fixes the pulling to the right shrink. I can have a look on Mac after Shabbos.
The issue is the
$(".expanded").each(function() {
sjs.expandSource($(this));
});
being triggered on every $(window).click(). I haven't tested this yet, but it seems that an if (event.target != scrollbar)
there would fix this.
I can confirm that it works in Windows/Chrome.
The following bug occurs in Chrome but not Firefox (so at least I have a temporary workaround :-)).
If there is a really long source (long enough that you need to scroll down to see the bottom), it's impossible to edit that source in Chrome. I click on the note to expand, and the note expands past the lower border of the screen. The edit link is below that. I try to scroll down but the act of scrolling requires a click, which automatically shrinks the note back to it's condensed size which doesn't have the edit link.