Setting `window.location` from JavaScript breaks the pagination

[mickael-menu-mantano]

Currently, if a publication uses JavaScript to set window.location, the current web view contents is replaced but the pagination view is not updated, so the current chapter basically disappears.

Instead, the navigator should handle setting window.location this way:

• If the href is part of the readingOrder, then treat the move as a jump to another location and update the pagination accordingly.
• If the href is an external URL, treat it as a click on an external link and prevent changing the current location.

A test EPUB is available here: https://github.com/JayPanoz/architecture/tree/touch-handling/misc/touch-handling

[mickael-menu]

@JayPanoz @danielweck Do you think it's a legitimate use case, to allow a book to set window.location directly?

[JayPanoz]

I can’t remember exactly which authoring tools use that for scripted books, especially FXL, but it’s not uncommon so it would break these files.

That said, and underlying in the original post, it can be abused pretty quickly – can recall trying funny experiments with that when discovering some security issues in some apps so I’d say maybe external URL should even have some kind of popup/message with the URL in plain text to confirm opening the link in Safari instead of a straightforward redirect.

[mickael-menu]

Okay thanks, my plan was to intercept any redirect in the web view delegate and translate it to either regular internal or external links.

[JayPanoz]

Just checked my experiments, so some further details re. “it can be abused pretty quickly”:

1. there’s window.location.href but in my experience window.location.assign() and window.location.replace() tend to be overlooked/forgotten;
2. data: URI tend to be forgotten as well.

For instance, if you do:

window.location.assign("data:text/html;charset=utf-8,%3Cbody%20oninput=%22document.querySelector('iframe').srcdoc=h.value+'%3Cstyle%3E'+c.value+'%3C/style%3E%3Cscript%3E'+j.value+'%3C%5C/script%3E'%22%3E%3Cstyle%3Ebody%7Bmargin:0%7Diframe,textarea%7Bwidth:100%25;height:50vh;float:left%7Dtextarea%7Bfont-family:monospace;font-size:11pt;line-height:1.4;width:33.33%25%7D%3C/style%3E%3Ctextarea%20id=h%20placeholder=HTML%3E%3C/textarea%3E%3Ctextarea%20id=c%20placeholder=CSS%3E%3C/textarea%3E%3Ctextarea%20id=j%20placeholder=JS%3E%3C/textarea%3E%3Ciframe%3E")

Then you end up with a lightweight interactive codepen on the current page – which can escalate quickly.

[mickael-menu]

I will keep it in mind, thanks for the insights!
The web view will probably intercept any kind of redirect, but I wonder how it will handle data:.

[danielweck]

In the NodeJS/Electron navigator implementation, all navigation events (including user-activated hyperlinks via <a href="URL"></a>, as well as scripted interactions such as window.location = URL) are intercepted and passed through a filter that determines whether to open a third-party web browser (external URLs), or to load the link as part of the current publication (local book navigation).