You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue has been documented in another thread on the Backpack for Laravel repository: Laravel-Backpack/CRUD#389
When opening the ElFinder, I receive the following error in the console: elfinder debug: [error] [elfinder] Unable to open "#".<br>Folder not found. Upon inspection, I've found the problem.
On the line 3895 of elFinder.js, there is an event bound on the window called message which call an additional request. When calling a new request, it aborts current requests of type open.
Now, some extensions installed on Chrome, Grammarly in my case, can cause problems. That extension was triggering the event message on page load, aborting the initial request of elFinder. When it was doing the .sync, the target param sent in get was empty, causing the error.
Now, the fix was easy, disabling the extension solved everything, but it is not practical. Would using a less generic name or a prefix instead of a namespace for the event be possible? It would solve that problem at least.
The text was updated successfully, but these errors were encountered:
This issue has been documented in another thread on the Backpack for Laravel repository: Laravel-Backpack/CRUD#389
When opening the ElFinder, I receive the following error in the console:
elfinder debug: [error] [elfinder] Unable to open "#".<br>Folder not found.
Upon inspection, I've found the problem.On the line 3895 of elFinder.js, there is an event bound on the window called
message
which call an additional request. When calling a new request, it aborts current requests of type open.Now, some extensions installed on Chrome, Grammarly in my case, can cause problems. That extension was triggering the event
message
on page load, aborting the initial request of elFinder. When it was doing the.sync
, thetarget
param sent inget
was empty, causing the error.Now, the fix was easy, disabling the extension solved everything, but it is not practical. Would using a less generic name or a prefix instead of a namespace for the event be possible? It would solve that problem at least.
The text was updated successfully, but these errors were encountered: