Bug #91227: TypeError: t.TYPO3.settings is undefined in popup of feedit - TYPO3 Core - TYPO3 Forge

Custom queries

12 LTS
Accessibility
Dashboard issues
Easy tasks
Extbase Issues
FAL Issues
FAL Sprint 2023
Hierarchical Issues
Issues reported for v11
JavaScript issues
JavaScript Issues (w/o Epics/Stories)
Most wanted Bugfixes
Most wanted Features
My open issues
New & Unassigned
No feedback within 90 days
Open Bugs
Open issues of 10
Page Tree Regressions after 2020-07-28
Recently modified
Regressions
Stabilization Issues
Usability or UX

Watchers (1)

Michael Rainer

Actions

Copy link

Bug #91227

closed

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

Added by Daniel Siepmann almost 4 years ago. Updated about 2 years ago.

Status:

Rejected

Priority:

Should have

Assignee:

Category:

Backend JavaScript

Target version:

Candidate for patchlevel

Start date:

2020-04-28

Due date:

% Done:

Estimated time:

TYPO3 Version:

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?

History
Notes
Property changes

Actions

Copy link

Updated by Daniel Siepmann almost 4 years ago

Description updated (diff)

Actions

Copy link

Updated by Oliver Hader almost 4 years ago

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...

Actions

Copy link

Updated by Daniel Siepmann almost 4 years ago

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

Open TYPO3 Backend
Login to Backend
Open Preview of a site via TYPO3 Backend (preview button)
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.

Actions

Copy link

Updated by Kurt Dirnbauer almost 4 years 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)

Actions

Copy link

Updated by Daniel Siepmann over 3 years 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.

Actions

Copy link

Updated by Michael Rainer almost 3 years ago

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

Actions

Copy link

Updated by Christian Kuhn almost 3 years 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.

Actions

Copy link

Updated by Michael Rainer almost 3 years 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

Actions

Copy link

Updated by Christian Kuhn about 2 years ago

Status changed from Needs Feedback to Rejected

hey. thanks for feedback. i hope it's ok to 'reject' here for now.

Actions

Copy link

Also available in: Atom PDF

Project

General

Profile

TYPO3 Core

Custom queries

Watchers (1)

Bug #91227

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

Updated by Daniel Siepmann almost 4 years ago

Updated by Oliver Hader almost 4 years ago

Updated by Daniel Siepmann almost 4 years ago

Updated by Kurt Dirnbauer almost 4 years ago

Updated by Daniel Siepmann over 3 years ago

Updated by Michael Rainer almost 3 years ago

Updated by Christian Kuhn almost 3 years ago

Updated by Michael Rainer almost 3 years ago

Updated by Christian Kuhn about 2 years ago