You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Make submenu properly size itself to fill available room and improve overlay positioning when pinch zoomed (#5660)
* progress on adding 2d flipping
* calculate max height of overlays using the overlay bottom instead of the trigger top
in the submenu case, the offset of the menu means we need to calculate the max height with respect to the overlay bottom not the trigger itself. Use overlay size instead of position so that we dont run into complexities with if we are receiving "bottom" or "top" as overlay coords
* fix some tests
* fix more tests
needed to refine the getDelta logic so that the popover position would be properly adjusted when top/bottom were outside the boundary and maxHeight wouldnt be adjusted to prevent that
* todo: question about what the actual behavior should be
* bounding the max height by the height of the boundary
* getting rid of flip and fixed edge flip code
mimic MacOS in how the submenus will simply be pushed up/down if they would exceed the boundary
* update left bottom postion tests
maxheight for leftbottom is calculated to the top of the boundary
* fixing remaining test
* some cleanup of old logic
* missed some last cleanup
* Fix overlay positioning when the boundary has been scrolled
* fix max height calc and Safari overlay positioning when already pinch zoomed in
* accidentally deleted too much
* forgot a set of parens ugh
* fix examples where triggers are placed at the bottom of the page and are scrolled into view
* this works, but why...
* fix logic
* update copy
---------
Co-authored-by: Kyle Taborski <ktabors@yahoo.com>
Co-authored-by: Robert Snow <rsnow@adobe.com>
// Safari will report a non-zero scrollTop/Left for the non-scrolling body/HTML element when pinch zoomed in unlike other browsers.
139
+
// Set to zero for parity calculations so we get consistent positioning of overlays across all browsers.
140
+
// Also switch to visualViewport.pageTop/pageLeft so that we still accomodate for scroll positioning for body/HTML elements that are actually scrollable
// For cases where position is set via "bottom" instead of "top", we need to calculate the true overlay top with respect to the boundary. Reverse calculate this with the same method
// If the container is the HTML element wrapping the body element, the retrieved scrollTop/scrollLeft will be equal to the
483
+
// body element's scroll. Set the container's scroll values to 0 since the overlay's edge position value in getDelta don't then need to be further offset
484
+
// by the container scroll since they are essentially the same containing element and thus in the same coordinate system
// Note that a crossAxis of 'bottom' indicates that the overlay grows towards the top since the bottom of the overlay aligns with the bottom of the trigger
0 commit comments