TYPO3 Core

• https://github.com/FriendsOfTYPO3/feedit/blob/master/Resources/Public/JavaScript/Modules/Edit.js#L18 seems to open the new window
• https://github.com/TYPO3/TYPO3.CMS/blob/master/Build/Sources/TypeScript/backend/Resources/Public/TypeScript/ContextHelp.ts#L40-L46 is retrieving the corresponding window object

I guess (did not test that) that the frontend window object is used which does not have required TYPO3.settings assigned...

I just found out that the following workflow works (most of the time):

1. Open TYPO3 Backend
2. Login to Backend
3. Open Preview of a site via TYPO3 Backend (preview button)
4. Start editing page content via feedit.

Note: Feedit opens a new tab in my Firefox browser. No PopUp or new Window.

Sometimes it is possible to close the new tab, and open another one via feedit. Sometimes it will not work, and above issue is raised.
Retrying (closing new tab and clicking button again) solves the problem from time to time.

I would have tested with chromium, but for some reason login to TYPO3 Backend does not work within Chromium, but only with this instance.

I've also noticed everything works fine and expected when using incognito mode. But I don't know the cause.
Also the whole installation feels faster in incognito mode. Even disabling all installed extensions doesn't make a difference, only switching to incognito mode.

I would be fine with closing the issue, if you don't have further ideas. Sounds like an edge case with the setup and browser.

same problem here with mac and chrome.

console log in new tab:

Uncaught TypeError: Cannot read property 'ContextHelp' of undefined
    at initialize (ContextHelp.js?bust=19a39e5c7ad3e5a3a9f468e58ff258ff4d7ef77c:13)
    at new i (ContextHelp.js?bust=19a39e5c7ad3e5a3a9f468e58ff258ff4d7ef77c:13)
    at Object.<anonymous> (ContextHelp.js?bust=19a39e5c7ad3e5a3a9f468e58ff258ff4d7ef77c:13)
    at Object.execCb (require-96bd1f40631d3c0d0c3bbb53eef6ac72.js:5)
    at i.check (require-96bd1f40631d3c0d0c3bbb53eef6ac72.js:5)
    at i.<anonymous> (require-96bd1f40631d3c0d0c3bbb53eef6ac72.js:5)
    at require-96bd1f40631d3c0d0c3bbb53eef6ac72.js:5
    at require-96bd1f40631d3c0d0c3bbb53eef6ac72.js:5
    at each (require-96bd1f40631d3c0d0c3bbb53eef6ac72.js:5)
    at i.emit (require-96bd1f40631d3c0d0c3bbb53eef6ac72.js:5)

Looks like the technical problem is the following. The JS files don't know any context except TYPO3 backend.
They also expect to be called within a popup opened from the backend.
Therefore they contain small logic to get the TYPO3 context from possible opener window and their top frame.

Poorly this doesn't work when being opened from frontend context, as the JS TYPO3 backend context does not exist. One could now go ahead and try to adjust all those files fetching the context. One could extend them to check one more opener. That way they would be able to work if the frontend was opened via "view" from TYPO3 backend.

Still that won't be a proper solution.

I'm not a JS pro and don't know whether there is any way to provide the context.

Is there any news?
I guess, it should also be available in the frontend context, shouldn’t it? Are there any security issues?

Christian Kuhn wrote in #note-7:

Hey. Thanks for your input.

In general I tend to reject the issue, though:
Only some BE JS is considered API (modals, for instance, I'd say) and core is constantly refactoring other JS without further notice.

Pulling stuff like FormEngine out of context and trying to render it standalone in frontend like feedit does is thus not as such directly maintained by core.

Extension maintainers of feedit or frontend_editing are of course free to submit core patches to reduce their headaches, though. But core maintainers don't have the direct responsibility to keep that usage in mind when refactoring backend JS.

Example: With v11, core is also going forward by exposing the inner module links as browser url (deep linking). Next logical steps are a refactoring of the module registration API, which would enable first patches to (finally) drop the main module iframes, which would have a lot of positive impact on JS BE global and module state.

So, core will go ahead in this area, feedit basically has to follow, but is free to create core patches to reduce headaches. If that does not happen, feedit will break and core won't do much about it on it's own.

I hope this PoV is reasonable and also hope that feedit gains enough traction to be kept as a working extension.

Hi Christian,

can understand the reasons, especially in a backend developers view.
I was not sure, if it's officially planned (core team) to open the backend forms also for frontend editing or not.
But when not, it all makes sense.
Thank you for the feedback.

Cheers,
Michael