Widget creation placement is off when window is scrolled - standalone html versions - a fix for this #419
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem - if you scroll the window at all, the placement of newly created widgets is off, sometimes by a lot.
How to recreate:
Here are some images from the virus model, doing this. This is not too bad but on more complex models or if the widow is not full height, the widgets can be added below the window view, which for new users can be very confusing i.e. where did my widget go?
Solution
I think I know why this is happening. The context menu collects the mouse pageX and pageY coordinates when it is activated. Those coordinates are then passed to the widgetController's createWidget function when a widget is chosen for creation.
Galapagos/app/assets/javascripts/beak/widgets/widget-controller.coffee
Line 17 in 8f9c59a
This code then gets the position of the .netlogo-widget-container element with getBoundingClientRect() and then minuses those left and top positions from pageX/pageY coordinates to get the position of the context menu relative to the .netlogo-widget-container element.
The problem is that .getBoundingClientRect() gets positions relative to the viewport. So if the top of the .netlogo-widget-container element is above the viewport the resulting 'top' numbers will by negative (can also occur on the x-axis if there is horizontal scrolling). Then a double negative occurs ( y - - coordinate) and instead of taking away, the y coordinates are actually added and the resulting widget is placed much further down.
I think the solution is simple - add window.scrollY and window.scrollX to account for any scrolling i.e.
adjustedX = Math.round(x - (rect.left + window.scrollX ))
adjustedY = Math.round(y - (rect.top + window.scrollY ))