Positioning popup in pure wikitext

Developers
, ,
#1

I just debug principle plugin’s context menu wrong position problem, so share it here.

Saq’s streams plugin popup a context menu in this way (this is how you can create your own context menu, or popup window under mouse click):

  1. $eventcatcher widget listens on event of element, like .stream-row. It can listen on many events, including swiped-right and right click
  2. $eventcatcher provides position of the mouse or finger by prividing variable <<tv-popup-abs-coords>> to all its children, and callbacks on it
  3. A callback like actions-swiped-right=<<swiped-right-actions>> on it, might contains a $action-popup
  4. $action-popup will use <<tv-popup-abs-coords>> or <<tv-popup-coords>> to compute the coordinates of popup element to show, the coordinates are putted into a state tiddler you provided, for example $:/state/sq-context-popup
  5. You can use $reveal widget’s popup mode, following position in $:/state/sq-context-popup tiddler, to position the context menu relative to <body>.

Why the position is relative to <body>? Accroding to TW core’s source code, it is acturally relative to offsetParent of the popup element, it is usually the document.body.

And if the parent container has If the parent container has scrolling, you will find that no matter how you scroll, the menu is in a fixed position relative to the page, and then the positioning will be wrong relative to the scrolled content.

So if the popup’s position is wrong:

  • Try to remove scrolling from one of the upper containers.
    • e.g. remove the height: 100vh; restriction or remove the overflow-y: auto; attribute
    • Or make container a offsetParent of the context menu, e.g. by adding position: absolute;top: 0;left: 0;
#2

If I’m understanding you correctly…

I’m not sure your solutions are reasonable approaches to fixing the problem. And did you mean remove the restrictions temporarily or modify one’s design approach to avoid them? ← ouch!

But really, if tv-popup-abs-coords is not working correctly when a parent element is scrolled, why not report a bug?

Calculating “true position” is not new. Indeed, it’s a “solved problem”. What the code should be doing is summing the offsetsTops/offsetLefts taking into account scrollTop and scrollLeft.

I’m probably missing your point… :confused: