The bug is when there is a scrollbar at the bottom of the screen the settings are not properly sized. At least this is the case with Chrome. I didn’t test other browsers. The fix is to replace this css rule:
In other words I am adding the max-height property. This is defined in the relevant element styling so we must use the !important hack. It would be better to fix the element styling though. I can’t find where in the framework code this styling is defined so I can’t propose this kind of fix. I see you use the google ajax api so I presume this is where it comes from. If this hunch is correct you may want to file a bug report.
Google ajax API? I’m not familiar with that. I guess you mean jquery and jquery UI. (Unless Google now owns jquery, which I guess wouldn’t surprise me)
I generated the css with the jquery theme manager, so everything should be in jqui-wkmain.css. Everything else (besides jquery an jquery ui) are hand-coded.
Edit: oh… I may have used bootstrap on wkstats v2. I can’t remember.
The element style is apparent and max-height is defined there. I don’t know where this element style comes from. I can’t find it in your code. But if I update the relevant jqui-wkmain.css.rule this element style has priority unless we use !important.
Ahh, that makes sense. googleapis.com hosts a lot of popular 3rd-party (and google) APIs. It’s often better to use google’s hosted version since they have servers everywhere.
That particular css is generated by javascript. The max-height is calculated based on screen size, but didn’t account for the possibility of a horizontal scrollbar. I’ll have to add that.
Yup. Not a bug per-se… Windows used to work the same way until they added snap-to-edge. But anyway, it doesn’t serve any purpose, so I could add a limit check.
Yeah. Fixing the element style is the way to go. When will this be ready? I suppose that with your current obligations and the backlog with wkstats it can take a while. Any chance that we can have the fix I proposed as a temporary stopgap until you can do the real thing?
Fixed. I used JS to set the submenu ‘top’ and ‘max-height’.
I also fixed the issue with horizontal scroll-bar interfering with height on Settings dialogs.
I’ll have to look at this one some other time. It seems to be related to dragging the dialog on a scrolled page. Probably need to factor scrollTop into the drag algorithm.
I don’t find in Item Inspector the element styling I had found in the heatmap. In Item Inspector height is set to auto and there is no max-height configured.
Asking this here because I can’t find anything about it when I google.
What is going on here? I know that JS arrays can be objects under the hood, which is why I ended up testing this, but it seems to present as a strange mix of the two here. Is there something I can search for to learn about this behavior?
let foo = [1, 2, 3];
foo['bar'] = 4;
foo
// [1, 2, 3, bar: 4]
Arrays are objects just like everything else in JavaScript, so you’re just arbitrarily assigning the property “bar” to the object. Notice that foo.length still returns 3.
Fixed. There was a second spot in the code that I missed. (It was actually the main spot to fix the problem. The other fix corrects the max-height when you click a tab).
I glanced at this again (or tried to…). Unfortunately, it seems this one is an issue with jquery UI. Wkof doesn’t handle the dragging
Would be interesting to see if it’s fixed in newer versions…
@rfindley is there a documentation somewhere on how to write a filter for the framework? Or do I have to look at some other script to see how it is done?