Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot use Choices if rendered from iframe #1057

Open
andreaskienast opened this issue Sep 20, 2022 · 2 comments · May be fixed by #1058
Open

Cannot use Choices if rendered from iframe #1057

andreaskienast opened this issue Sep 20, 2022 · 2 comments · May be fixed by #1058
Labels

Comments

@andreaskienast
Copy link

Describe the bug
Disclaimer: To be honest, this is a kinda special setup.

I have a modal window whose content contains a select field that is used to initialize Choices.js. There are two scopes where this modal may be opened:

  • in a simple standalone view
  • in a more complex environment with an iframe, where the modal is rendered in the top frame

In the latter case, I get the error "Expected one of the following types text|select-one|select-multiple". The issue is that the instanceof check for the passed element to initialize Choices.js does not work in case of an inter-frame communication. In my tests it was safe to check passedElement.constructor.name instead.

Since the fix is rather easy I'll push a PR ASAP.

To Reproduce
Steps to reproduce the behavior:

  1. In the iframe, have a callback that initializes Choices.js
  2. Open a modal with the matching select element on the top frame
  3. Execute the callback
  4. See "Expected one of the following types text|select-one|select-multiple"

Expected behavior
I expect that Choices.js works in the scenarios mentioned above.

Desktop (please complete the following information):

  • OS: Fedora Linux 36
  • Browser Chrome
  • Version 105
andreaskienast added a commit to andreaskienast/Choices that referenced this issue Sep 20, 2022
The previous check using `instanceof` fails in case the Choices.js
component is rendered in the `top` frame while the JavaScript actually
using Choices.js is in an iframe.

The conditions are changed to check for `constructor.name` now, solving
the issue.

Due to the rather messy constructor, some quirks like operational
chaining and explict type casts needs to be used to make the TypeScript
compiling process happy.

Fixes: Choices-js#1057
andreaskienast added a commit to andreaskienast/Choices that referenced this issue Sep 20, 2022
The previous check using `instanceof` fails in case the Choices.js
component is rendered in the `top` frame while the JavaScript actually
using Choices.js is in an iframe.

The conditions are changed to check for `constructor.name` now, solving
the issue.

Due to the rather messy constructor, some quirks like operational
chaining and explicit type casts need to be used to make the TypeScript
compiling process happy.

Fixes: Choices-js#1057
andreaskienast added a commit to andreaskienast/Choices that referenced this issue Sep 20, 2022
The previous check using `instanceof` fails in case the Choices.js
component is rendered in the `top` frame while the JavaScript actually
using Choices.js is in an iframe.

The conditions are changed to check for `constructor.name` now, solving
the issue.

Due to the rather messy constructor, some quirks like operational
chaining and explicit type casts need to be used to make the TypeScript
compiling process happy.

Fixes: Choices-js#1057
@seredniy
Copy link

+1. I have a similar problem.

@bplv112
Copy link

bplv112 commented Aug 8, 2023

+1 for me as well, I found that the issue is probably because of the use of instanceOf on ChoiceJS before initialization. On iframe this is unreliable. There could be also be some potential issues when the proto chain has been modified for some reason as well.

I think the best solution here would be to replace instanceOf check for something else like nodeName or anything else that is constant and persistent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants