Open mojoaxel opened 12 years ago
acutally it's a bit more complicated.
Problem 1: An Overlay can move relative to the viewport if its parent resizes or moves. So one enhancement would be to listen to changes of the overlay parent (usually application root) and reposition to trigger there aswell.
Problem 2: The same is true for the trigger element.
Problem 3: Problem 1 and 2 are not limited to the immediate parent, but to all parents up the chain. In case of Overlay, it's only one .. but the trigger could be buried deep inside a widget hierachy and listening to all the parents could be a PITA.
To solve the problem on a case by case basis you could add a resize/move listener to the element that you identified responsible for the shift and have that listener a) fire a move event on the trigger or b) call repositioning function of overlay directly (__fixPositions would have to be made public for that).
if an overlay is visible and the browser windows gets resized than the overlay moves relative to his parent and "gets lost"