-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Feature request - implement a way to avoid clash with third party "message" events #3432
Comments
This issue is stale because it has been open for 50 days with no activity. |
This issue was closed because it has been inactive for 14 days since being marked as stale. |
Would be great if this could be reopened, as this is still an issue. For example, I was trying to integrate monaco editor with elFinder, which also uses messages to communicate. But my suggestion would be to always include some elFinder specific piece of data in the payload, such as |
Also, what is that message listener for? I didn't find any place in the source where it triggers such an event, and when setting a breakpoint via the dev tools, I also didn't find any situation where it got triggered. Edit: The post message seems to happen on the PHP side where it creates a piece of JavaScript code that posts the message. The easiest solution as mentioned above I think would be to e.g. to add |
This can happen when integrating ElFinder with third-party frameworks (or widgets) on which we have no control.
Imagine that this third party framework include (somewere in his code) something similar to this (javascript decompiled code):
This piece of code is functional to the other widgets of the framework, and send, as payload, a string composed with a prefix and a list of numbers (in the example "ej23518,25636,63989,33834,63789").
If the integration between ElFinder and the framework is of a certain type, the message is also managed by ElFinder in this place:
The message is accepted because it satisfy the CORS condition, but when it tries to obtain an object from the payload, the "JSON.parse(res.data)" fails (because the payload is not a json object) and the code continue in the catch block. In the catch block, the execution of the "sync" method will cause ElFinder to reload its content, losing the current position on the tree.
Plus, we can not have full control on how many messages the third party framework will send and this will result in an unnecessary communication between the client and the server (continuous reload).
Since the problem is generic and very specific, my suggestion is to add a new option in options: a function (by default null) that if present will do a pre-evaluation of the payload and return true (if the message is for ElFinder) or false (if the message is not for ElFinder and, being so, it should not be managed).
As suggestion, the option could be:
This option can then be used in the "$(window).on('message.'" as follow:
I implemented this solution in my integration as follow:
And it is working fine.
If you find this solution reasonable, please include it in the next release of ElFinder. If you need, i can make the changes in a dedicated branch and then submit a pull request.
Thanks in advance for your attention.
ADDENDUM
I discovered that the following comment:
Can be problematic with some bundle tools.... the "@if" is apparently confused as a C# directive and can generate errors during the bundle process. If it is not important to leave this comment where it is, it can be useful to remove it.
The text was updated successfully, but these errors were encountered: