Update Popper to v2.x

[Johann-S]

• Docs
• Changes in Popover css to add a bit of space between the element and the popover
• Update to the latest popper.js version
• Conflict between Popper.js and our css, which block us to align right dropdown
  • Check responsive behaviour
  • Check behaviour in navbar
• Document the fallbackPlacement -> fallbackPlacements breaking change?
• Tighten bundlewatch limits before the final merge
• Update Popper docs links to v2 (search for https://popper.js.org/docs/ but don't blindly replace them!)
• Add more JS tests to cover the changes in this branch

Fixes #29842

Preview: https://deploy-preview-31178--twbs-bootstrap.netlify.app/

[Johann-S]

Hi our @twbs/css-review team ❤️

Would you help me here ? I have some css issues on this migration

[MartijnCuppens]

Changes in Popover css to add a bit of space between the element and the popover

Is this just a matter of setting the offset in popper?

Conflict between Popper.js and our css, which block us to align right popover

What is this exactly? is it the alignment of the arrow?

[Johann-S]

Is this just a matter of setting the offset in popper?

I tried to do that, but it does nothing 😟 so I think with a bit of CSS we can change that easily to avoid that:

What is this exactly? is it the alignment of the arrow?

Sorry I meant on our dropdown. See:

[jquense]

Hey folks, we tried to preemptively upgrade to popper v2 in react-bootstrap for bootstrap 4 and thought it might be helpful top share what we learned:

tl;dr; Proper popper v2 support requires bigger CSS changes to the tooltip, popover, and dropdown menu

The slightly longer version is that popper no longer considers margins when calculating offsets, which ius why the Popover and dropdown are positioned incorrectly. To fix, all distance should be set via the popper offset modifier.

Another related consequence to this is that arrow positioning that depends on creating space via a padding (the tooltip) also doesn't work well anymore (maybe never). The issue there is that when using auto positions or flip the dimensions of the popper element will change if the tooltip is moved to a different axis (b/c x and y padding is changed). Because the offsets were calculated uses the old box, the newly flipped tooltip will be incorrectly positioned until popper runs again.

Popper docs and Tippy both avoid this problem by only using the offset modifier and offsetting the arrow relative to the container (e.g left ; -4px)

None of this is particularly hard to fix BUT it has the consequence of needing config for arrow size available in JS, or doing some getComputedStyle shenanigans in a offset modifier (which does accept a function but doesn't pass in the actual popper element).

[jquense]

I'd also add that I'd be happy to help out getting this in. Popper v2 is awesome and tiny

[mdo]

@jquense We'll take any help you can give! Would love to get this included in Alpha 3!

[XhmikosR]

Rebased it, hopefully nothing broke :)

[XhmikosR]

This needs a check @ffoodd for RTL (and the whole PR)

[ffoodd]

On the RTL side, this will be translated to left: auto.
If this part is meant to reset initial positionning, maybe we should reset both sides? If so, it'll need #{"/* rtl:ignore */"} as seen a few lines below.

Edit: in fact it seems to behaves as expected. Only the arrows aren't flipped.

[ffoodd]

On the RTL part, arrows aren't flipped in RTL so there's something to tackle there.

After trying things out, I think .popover-arrow should be processed by RTLCSS (meaning drop #{"/* rtl:ignore */"} in every .bs-popover-* > .popover-arrow { … }).

[ffoodd]

On the RTL side, this will be translated to left: auto.
If this part is meant to reset initial positionning, maybe we should reset both sides? If so, it'll need #{"/* rtl:ignore */"} as seen a few lines below.

Edit: in fact it seems to behaves as expected. Only the arrows aren't flipped.