Widget creation placement is off when window is scrolled - standalone html versions - a fix for this

[drocks13]

Problem - if you scroll the window at all, the placement of newly created widgets is off, sometimes by a lot.

How to recreate:

1. Download any of the models as standalone HTML
2. Open it up
3. Go into authoring mode
4. Scroll down to the bottom of the editing area (depending on the model, if it does not have a lot of widgets, you may need to open up one the accordions e.g. code tab usually is quite large, and increases the size of the window, to really see the effect)
5. Right click on the editing area to bring up the context menu
6. Choose any of the widgets to add and then you will see it gets added further down than where you right clicked to bring up

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

createWidget: (widgetType, x, y) ->

.

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.

 rect      = document.querySelector('.netlogo-widget-container').getBoundingClientRect()
 adjustedX = Math.round(x - rect.left)
 adjustedY = Math.round(y - rect.top)

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 ))

[LaCuneta]

Nice, thank you for the detailed write-up of the problem and the solution! I tested a few scenarios and everything works well.