Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add error handler for iframe contents #454

Closed
Jaifroid opened this issue Dec 12, 2018 · 5 comments
Closed

Add error handler for iframe contents #454

Jaifroid opened this issue Dec 12, 2018 · 5 comments

Comments

@Jaifroid
Copy link
Member

Since the iframe can contain JavaScript that may run incompletely in jQuery mode, or even in SW mode where inline and certain other methods may be banned by Content Security Policies, it would seem like a good idea to add some global error handling for JavaScript in the iframe. In some app contexts (e.g. UWP), this can also prevent an app crash due to JS over which we have little control.

In Kiwix JS Windows, I have been experimenting with adding such a handler on first load of iframe contents. It looks like this:

// Set a global error handler for iframe
window.frames[0].onerror = function (msg, url) {
    console.log('Error caught in ZIM contents [' + url + ']:\n' + msg);
    return true;
};

Return true prevents the system registering the error, and in UWP context, it prevents the app from crashing and closing. We can probably address the iframe without .frames[0] -- that's just what has worked for me on first go.

I think it might be useful to have this here, upstream, rather than just in Kiwix JS Windows. Note that this is not a global error catch for the JS in our app, just for any JS running in the iframe. It would be possible to add some global error catching as well, but only for production, obviously not for development. But I think that would be another issue.

@Jaifroid Jaifroid self-assigned this Dec 12, 2018
@Jaifroid
Copy link
Member Author

I think this issue might be indirectly related to #43.

@mossroy
Copy link
Contributor

mossroy commented Dec 12, 2018

I understand it's necessary on UWP, even if it's a strange error handling design by Microsoft IMHO.
On other platforms, it's not useful. And we need to check it can not cause any harm.
For example, we should use the same log level : if we catch an error, it should be logged as an error.
And we need to check that it does not prevent some developer tools features to work, or hide some information : when an error is catched by the browser itself, it might give more information than an error message (like the source file and line where the problem occured, and maybe some other info?)

@Jaifroid
Copy link
Member Author

OK, if it's only useful for UWP, maybe I should implement it only in Kiwix JS Windows? It's genuinely useful there, because otherwise I have to attempt to neutralize any JS on the page that can cause an exception (especially onclick type event handlers). I agree that it's strange error handling. They have global errorhandling for XAML / C++ etc., but none for HTML/JS UWP apps (maybe they expect developers to use native JS error handling).

However, even in non-app usage, I seem to remember cases where an error on the page -- especially an error caused by window.onload in the iframe -- can stop further processing of JavaScript in browsers, so that even though the page doesn't close / crash, it can prevent things like extraction of images? Could still be useful in such situations? I seem to remember that was the case with #430, but that error only affected Edge, so I don't actually know how other browsers handle an exception in the iframe's window.

If you don't think it's useful beyond UWP, I'll close this issue.

@mossroy
Copy link
Contributor

mossroy commented Dec 14, 2018

Sorry for the delay : yes, I think it's currently not useful except for UWP, and agree it would be better to implement it only in Kiwix JS Windows.

@Jaifroid
Copy link
Member Author

OK, thanks! Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants