Popper-core: Popper element is not positioned correctly when reference elements is in an offset iframe

[maciejszpyra]

CodePen demo

https://codepen.io/maciejszpyra/pen/JjPRXrm

Steps to reproduce the problem

1. Have a reference element inside iframe
2. Iframe needs to be offset
3. Create Popper alignment

What is the expected behavior?

That popper element will be correctly positioned.

What went wrong?

It appears that popper is ignoring the position of the iframe in the parent document when calculating the popper element offset.

Any other comments?

Is there any option we can set to make this work, do we need to crate modifier to fix this or is this just a bug?

[IGreatlyDislikeJavascript]

@FezVrasta +1 for this issue, I've had this reported for Bootstrap Tourist (tour step in iframe not aligned to element), and the underlying cause is popper.js not obeying iframe offset.

I think this needs to be fixed in popper.js. Although we can manually shift the popover by getting the element in the iframe and setting an offset initially, if the content in the iframe is responsive and the layout changes then it becomes complicated to solve this outside of popper.js.

In addition, BS4 doesn't expose all the popper options, so it's actually impossible in some scenarios (as per my reply to you in my repo).

Thanks!

[maciejszpyra]

I linked better codepen example

[cytrowski]

Have you considered using the modifiers? https://github.com/popperjs/popper.js/blob/master/docs/_includes/popper-documentation.md#modifiers--object

[FezVrasta]

May someone test this bug with @popperjs/core@next?

[cytrowski]

May someone test this bug with @popperjs/core@next?

I can do it Today :) stay tuned

[cytrowski]

Sadly it's even worse: https://codepen.io/cytrowski/pen/MWYepgL

Right now to see the popper element you have to resize the window. With 1.16 it's at least visible.

[atomiks]

Hi @cytrowski you need to be trying the latest @next. I did and the bug is there, but it's positioned where the button would "originally" be if the iframe was not offset. So we need to take into account iframes' position on the document as well? 🤔

[FezVrasta]

https://codepen.io/FezVrasta/pen/dyPXvMp

[atomiks]

That doesn't work @FezVrasta

This one works: https://codepen.io/atomiks/pen/qBENrNZ

[FezVrasta]

Thanks, so it looks like v2 is not worse, but not better, than v1

[cytrowski]

Hi @cytrowski you need to be trying the latest @next. I did and the bug is there, but it's positioned where the button would "originally" be if the iframe was not offset. So we need to take into account iframes' position on the document as well? 🤔

Yes, that's the issue we experience :) Thank you for looking into that

[cytrowski]

Just a quick question @FezVrasta - are you going to fixing this in the next week or so? If not I can try doing the PR with a fix. Also I think it's worth fixing in 1.17 as well as in the latest version

[FezVrasta]

Right now I'm working in preparation of the release of Popper 2, so I doubt I'll have time to look at this issue. If you'd like to send a PR that'd be great.

I don't plan to continue the development of the 1.x branch if not for security vulnerabilities.

[atomiks]

The easiest fix for this is just to put the popper element in the same iframe context as the reference element. Having them disjoined in different documents breaks ARIA IDs, so there are accessibility concerns with doing this in the first place. It doesn't seem like this is worth it to fix/handle due to that.

[FezVrasta]

Closing as per above comment.

[cytrowski]

The easiest fix for this is just to put the popper element in the same iframe context as the reference element.

Sadly that's a no-go in my use case (page layout requires the popper element to be in the parent context - It has to be visible and not cropped by the iframe boundaries)

Having them disjoined in different documents breaks ARIA IDs, so there are accessibility concerns with doing this in the first place.

What if I'm able to guarantee the uniqueness of IDs across the whole page (including iframes)?

It doesn't seem like this is worth it to fix/handle due to that.

As far as I know iframes can be perfectly accessible and in some cases (microfrontend) they are the only reasonable way to go. I would consider putting some effort in fixing this issue (I can work on it) https://webaim.org/techniques/frames/

[FezVrasta]

If you'd like to add support for this, consider to create a replacement for the popperOffsets modifier, it should be enough to make you able to add the necessary logic to handle iframes.

[atomiks]

What if I'm able to guarantee the uniqueness of IDs across the whole page (including iframes)?

When I tested using VoiceOver, having focus on the button didn't announce the popper content with aria-describedby. The IDs are only referenced in the same document context :\

[cytrowski]

What if I'm able to guarantee the uniqueness of IDs across the whole page (including iframes)?

When I tested using VoiceOver, having focus on the button didn't announce the popper content with aria-describedby. The IDs are only referenced in the same document context :\

Can you share your example? @atomiks

[atomiks]

In the iframe:

<button aria-describedby="popper">My button</button>

In the main document:

<div id="popper">My popper</div>

When inside the iframe focusing the button, "My popper" is not announced like it should be

[cytrowski]

https://github.com/popperjs/popper-core/issues/791#issuecomment-578678672 - I'm not sure it's a valid use case for aria-describedby attribute considering the fact that the dialog body may not be available on button focus - only after it's clicked.

[atomiks]

That pattern is for tooltips rather than interactive popovers. I'd guess focus management can handle interactive popovers.

[cytrowski]

https://github.com/popperjs/popper-core/issues/791#issuecomment-578681515 - in that case I believe tooltip body can live inside the iframe (won't affect layout that much). I'm focused more on interactive ones. We can mention the problem in the docs.

UPDATE: I'm thinking about inline edit with datepicker appearing while writing a date (some kind of macro, detecting the pattern you use while writing)

UPDATE: I'm reviewing other use cases again to be 100% sure I need to fix it here or in my app.

[luminaxster]

Sadly, I got to inject the iframe offset directly to "fix" it:

const clientRect = iFrameContainer.getBoundingClientRect();
const containerOffsetTopPos = clientRect.y;
const containerOffsetLeftPos = clientRect.x;
....
modifiers={[
                                    {
                                        name: 'offset',
                                        options: {
                                            offset: [
                                                containerOffsetLeftPos,
                                                containerOffsetTopPos
                                            ],
                                        },
                                    }]}

iframe offsets used to work out of the box in V1 =(.

[tounsoo]

I am not really seeing any solution here? no?