nkbt/react-collapse

Browser zoom can cause expansion to remain incomplete, and break nested content expansion

Closed this issue · 4 comments

When browser is zoomed in some cases the IDLING state is never reached when expansion animation has completed. This in turn means that height: auto; never gets applied and any changes to nested content dimensions will not be respected by the wrapper, instead cutting it off or leaving extra space

This is caused by clientHeight being an integer rounded from a subpixel value, when comparing the from/to clientHeights of wrapper and content. The subpixel values in some cases appear to be rounded in different directions causing a permanent off-by-one measurement, and so triggers another resize attempt instead of making it the if(RESTING) -> IDLING conditional and just stays in RESIZING state indefinitely until further interaction with a hard style 'height: ${to}px' on the wrapper

Below images show the problem in debugger - as you can see it is not a bounding box measurement error as there are no borders/padding/margin etc applied to the wrapper or content. It also doesn't occur at normal browser zoom

Example - Chrome 59, OSX, Zoomed @75% on retina display - but also fails at various other zoom levels (not 100%)...

Screenshot of breakpoint after expansion animation completed, in a RESTING state, content.clientHeight -> 79, wrapper.clientHeight -> 80, will re-enter RESIZING state indefinitely...
image

And in computed size inspector you see the wrapper.clientHeight -> 80 was measured when the element actually had height: 79px applied, and the computed size, with no borders/padding etc was also 79, proving rounding in wrapper.clientHeight is incorrectly reported
image

Same issue here, not even on zooming, In the case of a parent and child collapsible, the parent doesn't completely resize its height when the child gets to open mode.

Any updates regarding that issue?

Bump

nkbt commented

As new react-collapse@5.0.0 is released https://github.com/nkbt/react-collapse/releases/tag/v5.0.0 this issue has been most likely already solved.

Please feel free to re-open if the issue persists