Previewing articles inline

phiw13 · 2024-12-02 06:44:31

I think I figured out why I have those problems with the iframe not loading in Safari.

It has nothing to do with any type of CSP
The content of the <iframe/> is actually loaded.
it has all todo with the source loading a script: script src="/path/to/script.js"></script>

The reason: this style block is left as first node after the opening <html> element.

<style id="HIDEHTML">html { opacity: 0.0 !important;}</style>

I think it should be removed by a script (textpattern.js) at some point. That does not happen on my test sites (localhost).

The Safari console spits out this when loading the iframe:

Blocked script execution in 'about:srcdoc' because the document's frame is sandboxed and the 'allow-scripts' permission is not set

with a little pill thing containing the number 3 (the source page only loads one script). When adding some CSP –same as dev-demo, or stricter– and remove the one <script /> then the same problem happens, with the little pill indicating 2.

Ideally I would need to test that some more on a live server, but that will have to wait some other day. I’ve spend already enough time on this, for a feature that offers little to no value to me. Viewing the page in a separate tab works perfectly fine, draft/pending/live status.

(I think for Safari sandbox really means isolate completely)

etc · 2024-12-02 08:00:36

giz wrote #338394:

Would it be feasible to inject the excerpt/body textarea contents into the iframe using javascript? We know which section/page/form the article uses, and so can identify where in the iframe the injection needs to happen.

They need (eventually) to be textiled first, right? The few js textile parsers that I’ve tested are outdated, so we have to make an excursion to the server side. And what if the body contains txp tags? Parsing them in js is merely impossible. And how would you retrieve page/form templates without pinging the server?

Also, you can change section/form ‘on the fly’ while previewing, without actually saving the article.

I’m using the Preview Dialog (with <details> tags) as a guinea-pig in my TXP5-style-library efforts. jqui be gone (I suspect the class names will hang around in the html for backwards-compatibility of admin-themes).

jQUI does its job, but if we manage to replace it with lightweight vanilla UI, some class names might be revised if theme authors find it pertinent.

etc · 2024-12-02 08:05:11

You’d need to debug it yourself, I’m afraid. Tested and retested, Safari works for me on the demo site.

phiw13 · 2024-12-02 08:19:39

etc wrote #338397:

You’d need to debug it yourself, I’m afraid. Tested and retested, Safari works for me on the demo site.

You want a login to my test site ? Send me an email and I’ll set up an account where you can see for yourself.

etc · 2024-12-02 09:19:50

phiw13 wrote #338398:

You want a login to my test site ? Send me an email and I’ll set up an account where you can see for yourself.

Sure I can test, the mail address is in my profile. But if it does not work for you on the demo site, the problem seems to be on the client side. I don’t remember which Safari version I have tested.

Anybody with Safari, can you test shift-click the View link on Write tab, please?

phiw13 · 2024-12-02 09:32:41

etc wrote #338399:

[…]

On the demo site, I added a script to the <head> of the archive page template

<script defer src="./scipt/sndsp.min.js"></script>

I then accessed the only article, shift-click on the “View” link. Result below (screenshot):

dev.l-c-n.com/_b/Screenshot%202024-12-02%20at%2018.24.19.png

–^–

I don’t see any email address in your forum profile only the forum email link.

etc · 2024-12-02 09:45:08

Ah. Scripts surely won’t work in sandboxed iframes. If you are absolutely confident of your site content, unchecking ‘sanitize’ should work. Another option would be to expose the iframe sandbox attribute to site admins, for fine-tuning.

But, as you say, our time can be better-spent :-)

I’ve just tested Sandspace, it works for me locally, in Firefox, though.

giz · 2024-12-02 17:09:14

etc wrote #338396:

They need (eventually) to be textiled first, right?
Also, you can change section/form ‘on the fly’ while previewing, without actually saving the article.

They’ve been textiled already; the html in the preview tab would be the source. Similarly, current section etc. is also available.

Anybody with Safari, can you test shift-click the View link on Write tab, please?

It works, but I also get error Blocked script execution in 'about:srcdoc' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.

.

I’m not wild about splitting preview functionality across 2 areas; doesn’t a dedicated ‘preview page’ link belong in the Preview modal?

etc · 2024-12-02 18:13:46

giz wrote #338407:

They’ve been textiled already; the html in the preview tab would be the source. Similarly, current section etc. is also available.

They aren’t, until you click Preview button, which makes a call to the server (check the console). We could populate them on page load, but then you’d have to save the article to refresh the preview.

It works, but I also get error Blocked script execution in 'about:srcdoc' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.

That’s not an error per se when the frame is sandboxed. Otherwise (malicious) public side scripts might be able to access the admin side. If you site is totally under your control, just uncheck ‘Sanitize’ checkbox, but I’m very sceptical re doing it by default.

Also, that’s what your site visitors with disabled js will see.

I’m not wild about splitting preview functionality across 2 areas; doesn’t a dedicated ‘preview page’ link belong in the Preview modal?

Me neither, but putting it inside div.txp-dialog along with body/excerpt preview pane yields double scrollbars when jQUI does its job. We can revisit it in txp 5.

giz · 2024-12-02 20:02:43

etc wrote #338408:

They aren’t, until you click Preview button, which makes a call to the server (check the console). We could populate them on page load, but then you’d have to save the article to refresh the preview.

Agreed. In txp 5 we can roll everything into the preview tab. I’m using <details> to control visibility of the panes, and their contents can either be inline on page load, or loaded asynchronously. A Page Preview iframe can be triggered asynchronously as required, and we could use the html pane as a source for populating the iframe.

etc · 2024-12-02 20:25:36

etc wrote #338408:

If you site is totally under your control, just uncheck ‘Sanitize’ checkbox, but I’m very sceptical re doing it by default.

To develop a little more, try unsanitized inline preview of an article containing

<script>window.parent.document.getElementById('title').value = 'Hacked!';</script>

and enjoy your new article title.

phiw13 · 2024-12-03 01:00:49

etc wrote #338401:

Ah. Scripts surely won’t work in sandboxed iframes. If you are absolutely confident of your site content, unchecking ‘sanitize’ should work. Another option would be to expose the iframe sandbox attribute to site admins, for fine-tuning.

Yes, you can do that for “Draft” or “Pending” articles, but not for “Live” articles.

Live article are always sandboxed, (there is no checkbox to toggle “sanitise”)

<iframe id="preview-frame" name="preview" tabindex="-1" class="txp-dialog ui-dialog-content ui-widget-content" sandbox="" srcdoc="…………"</iframe>

draft article, (checkbox toggle off)

<iframe id="preview-frame" name="preview" tabindex="-1" class="txp-dialog ui-dialog-content ui-widget-content" srcdoc="…………"</iframe>

For me, what is interesting is the possibility to (pre-)view changes / edits to live articles without saving (like: verifying that my edits are correct, code wise). If I save the article then the changes are immediately reflect on the public side for all to see. I can do that sanity check without problems with the preview dialog – including sanitised view. Having the full view of the article doing that in an iframe is a bonus.

I am not at all convinced a “Live” article should be sandboxed in the iframe the way it is now.

And of course I am trusting the code surrounding the article (outside of article body or excerpt).

PS – a annoying side effect of the sanitised view in the iframe is that the reviewer (or author) cannot locate where the potentially dangerous elements are. At least they are some bit visible in the pre-view dialog

–^–

I’ve just tested Sandspace, it works for me locally, in Firefox, though.

Yes, that issue has nothing to do with the admin theme in use. And yes Firefox behave differently than Safari.

Textpattern CMS

Textpattern CMS support forum

#13 2024-12-02 06:44:31

Re: Previewing articles inline

#14 2024-12-02 08:00:36

Re: Previewing articles inline

giz wrote #338394:

#15 2024-12-02 08:05:11

Re: Previewing articles inline

#16 2024-12-02 08:19:39

Re: Previewing articles inline

etc wrote #338397:

#17 2024-12-02 09:19:50

Re: Previewing articles inline

phiw13 wrote #338398:

#18 2024-12-02 09:32:41

Re: Previewing articles inline

etc wrote #338399:

#19 2024-12-02 09:45:08

Re: Previewing articles inline

#20 2024-12-02 17:09:14

Re: Previewing articles inline

etc wrote #338396:

#21 2024-12-02 18:13:46

Re: Previewing articles inline

giz wrote #338407:

#22 2024-12-02 20:02:43

Re: Previewing articles inline

etc wrote #338408:

#23 2024-12-02 20:25:36

Re: Previewing articles inline

etc wrote #338408:

#24 2024-12-03 01:00:49

Re: Previewing articles inline

etc wrote #338401:

Board footer