Safari: Loads preview link in window instead of in off-canvas dialog

We should see if this impacts the off canvas dialog outside of the context of SPP.

I wonder if we need to include a e.preventDefault(); to inform Safari that we're taking over the behavior.

This still appears to be an issue in 2.1.x. Bumping up the priotity.

I'm encountering the same issue. Could 🐛 Dialog hidden submit buttons don't work in Safari Needs work have something to do with it? I tried the last patch, but that doesn't fix it. It could also have to do with one of the Safari touch event quirks. I played around with the code a bit, but couldn't get it to work.

This (rightfully) came up in the Starshot thread about SPP. Assigning it to remind myself to take another look.

I've taken a look at how same page preview is working with Safari 17.4.1 and I can reproduce the bug. It took me a bit to get dev tools open so I can view the javascript console log.

Whatever this error is, it is hidden by the number of TypeError messages that Safari is giving out. Here's a list of files Safari has errors with:

• toolbar.js
• MenuModel.js
• ToolbarModel.js
• BodyVisualView.js
• MenuVisualView.js
• ToolbarAuralView.js
• ToolbarVisualView.js
• MenuVisualView.js

None of these files have anything to do with our module. In fact, Safari didn't log one message; Error, Warning or otherwise about Same Page Preview.

It's already odd, that whatever error is in our way here is only happening on Safari. But now it isn't clear if Safari has an issue with our module or if it's just errors with Drupal's new toolbar.

sorry havent found time earlier during the weekend to jump over from the github issue into this one. I think i might have found something that that is at least within the same_page_preview code and might be a potential clue?

I've just git cloned the latest state of starshot another time and required 2.1.x-dev from same_page preview and also switched off the aggregation of css and js. the console error when previewing one of the two nodes available is:

[Error] TypeError: null is not an object (evaluating 'previewOnHiddenField.value')
	(anonymous function) (drupal.js:64)

switching to the source view:

(function(Drupal, drupalSettings, drupalTranslations, console, Proxy, Reflect) {
    Drupal.throwError = function(error) {
        setTimeout(() => {
            throw error;
        }, 0);   (the inline error shown here is: <strong>null is not an object (evaluating 'previewOnHiddenField.value'</strong>))
    };

if i uninstall the navigation module as well as gin toolbar and switch from gin to claro with the starship install i get the following error:

TypeError: null is not an object (evaluating 'previewOnHiddenField.value*)
(anonymous function) — drupal.js:64
setTimeout
(anonymous function)  drupal.js:63
(anonymous function)  drupal.js:168
forEach
(anonymous function)  drupal.js: 162
(anonymous function)  big_pipe.js:153
Global Code - big_pipe.js:184

Cool. Seems like we're make progress.

previewOnHiddenField is indeed defined in same-page-preview.js, line 18.
It is used in only 1 place, when initializing our code.

But perhaps it is the selector we have chosen to use that Safari takes objection with (since it retrieve null, before we invoke a method on it).

The full line of code is previewOnHiddenField = document.querySelector('[data-drupal-selector="edit-ssp-preview-enabled"]'),

Next Steps

• Test the selector in isolation on Safari
• Add defensive programming tatics that detects if object is null and attempt secondary object retrieval logic if needed.

I believe I have a fix for this ready. Safari was choking on our uses of dispatchEvent. I'm not sure why - Safari supports dispatchEvent. Changing to click() made Safari happy again.

Thanks @rkoller for the help debugging here. Super helpful.

> Add defensive programming tatics that detects if object is null and attempt secondary object retrieval logic if needed.

I don't think this was the root cause, but I pushed up a commit that should protect from this as well using optional chaining.

Marking as fixed since this was merged in.

Automatically closed - issue fixed for 2 weeks with no activity.