Bug #91227

TypeError: t.TYPO3.settings is undefined in popup of feedit

Added by Daniel Siepmann over 1 year ago. Updated 7 months ago.

Status:
Needs Feedback
Priority:
Should have
Assignee:
-
Category:
Backend JavaScript
Start date:
2020-04-28
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
10
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

When using feedit https://github.com/FriendsOfTYPO3/feedit with current TYPO3 master, and one edits a content element in frontend, a popup with url

https://example.com/typo3/index.php?route=%2Frecord%2Fedit&token=d8eb628510e9d24a03e47b8cc425cc57536e1f9a&edit%5Btt_content%5D%5B36%5D=edit&noView=0&feEdit=1&returnUrl=%2Fabout-me.html%23c36
is opened.
This shows the backend edit form of the content element.
The loading animation does not stop, and browser console shows:

TypeError: t.TYPO3.settings is undefined
ContextHelp.js:33
    initialize ContextHelp.js:33
    i ContextHelp.js:26
    <anonymous> ContextHelp.js:96
    execCb require.js:5
    check require.js:5
    enable require.js:5
    bind require.js:5
    emit require.js:5
    each require.js:5
    emit require.js:5
    check require.js:5
    enable require.js:5
    bind require.js:5
    emit require.js:5
    each require.js:5
    emit require.js:5
    check require.js:5
    enable require.js:5
    init require.js:5
    O require.js:5
    completeLoad require.js:5
    onScriptLoad require.js:5

Reproducable with Firefox "75.0 (64-bit)" on Ubuntu 20.04 LTS.

I don't see any change to the ContextHelp.ts file which broke the behaviour, maybe something else is involved?

#1

Updated by Daniel Siepmann over 1 year ago

  • Description updated (diff)
#2

Updated by Oliver Hader over 1 year ago

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

#3

Updated by Daniel Siepmann over 1 year ago

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.

#4

Updated by Kurt Dirnbauer over 1 year ago

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)
#5

Updated by Daniel Siepmann over 1 year ago

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.

#6

Updated by Michael Rainer 7 months ago

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

#7

Updated by Christian Kuhn 7 months ago

  • Status changed from New to Needs Feedback

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.

#8

Updated by Michael Rainer 7 months ago

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

Also available in: Atom PDF