Bug #78401
closed
Workspaces preview page is broken
Added by Marco Bresch over 7 years ago. Updated over 5 years ago.
100%
Description
Since #52877 the JavaScript at the preview page of workspaces is broken:
JavaScript Error in sysext/backend/Resources/Public/JavaScript/ContextHelp.js line 48:Uncaught DOMException: Blocked a frame with origin "http://t3.dev" from accessing a cross-origin frame.
Files
| Schermata 2018-05-02 alle 18.21.14.png (90.1 KB) Schermata 2018-05-02 alle 18.21.14.png | Riccardo De Contardi, 2018-05-03 00:05 |
Updated by Marco Bresch almost 7 years ago
Uuh... I did not recognize that I am the assignee of this issue. I will have a look at the coding night in Malmö.
Updated by Xavier Perseguers almost 7 years ago
You're not the assignee but it looked like this ticket was somehow "forgotten".
But cool if you can have a look on your own!
Updated by Alexander Opitz over 6 years ago
- Status changed from New to Needs Feedback
What is the state of this issue? Did you have time to look into the issue?
Updated by Alexander Opitz almost 6 years ago
- Status changed from Needs Feedback to New
Spoke with Riccardo and it is still present.
Updated by Riccardo De Contardi almost 6 years ago
Steps to reproduce it on 8.7.13:
1) create custom worskpace
2) create a page and some content
3) modify the content in the workspace
4) click on the view button to preview the page with the "workspace bar"
5) use chrome console to see errors
results: see attached screenshot
Updated by Alexander Opitz almost 6 years ago
- Status changed from New to In Progress
- Assignee set to Alexander Opitz
Updated by Alexander Opitz almost 6 years ago
The issue behind this is CORS and the usage of setting "document.domain" ... see https://developer.mozilla.org/en-US/docs/Web/API/Document/domain
The ContextHelp.js searches for the real backendWindow (from which the Workspace preview was opened as "popup").
The Workspace Preview and Review system uses "document.domain" to set a Domain (since minimum TYPO3 4.5) for CORS in the iframes but as the real backendWindow do not set such thing we are decoupled (in the CORS view).
1) Remove all document.domain things from workspace
- This worked as expected, as the real backendWindow, the "popup" and the iframes inside the "popup" are loaded from same domain. The mentioned parent.resize functionality seams an old comment, slider/tabs & co worked correctly.
- I tested on Linux with
- Chrome 65.0.3325.181
- SeaMonkey 2.49.2
- Firefox 59.0.2
- On Windows
- InternetExplorer 11.0.9600.18977
- Firefox 59.0.3
- Someone should test this with IE
- This needs then also added to all PopUp/Wizards which try to communicate with this backendWindow
- This would be a breaking change ... also inside backporting to 8 LTS
- Could produce more hassle then it resolves
- IMHO this is not a real solution as we may later come up to a point where we need to communicate with backendWindow
Summa Summarum, I would favor solution 1.
Updated by Alexander Opitz almost 6 years ago
ckeditor seams to use an extra function for IE to circumvent an CORS issue there:
Updated by Gerrit Code Review almost 6 years ago
- Status changed from In Progress to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/56843
Updated by Gerrit Code Review almost 6 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/56843
Updated by Gerrit Code Review almost 6 years ago
Patch set 1 for branch TYPO3_8-7 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/56918
Updated by Alexander Opitz almost 6 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 9f1e15486bd4de700649bd84491831dea4431c4a.
Updated by 