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

window.onload does not fire in a .mht file #8

Open
Siemenskun opened this issue Jun 23, 2019 · 3 comments
Open

window.onload does not fire in a .mht file #8

Siemenskun opened this issue Jun 23, 2019 · 3 comments

Comments

@Siemenskun
Copy link

Siemenskun commented Jun 23, 2019

I don't know is it an issue of Pale Moon or MozArchiver, but it worked fine with old Firefox and UnMHT.
The event window.onload does not fire. A simple example from MDN (https://developer.mozilla.org/en-US/docs/Web/API/Document/DOMContentLoaded_event#Live_example) give me this if I execute it in a .mht file (testcase.mht in the attachment)

readystate: interactive
DOMContentLoaded

It should be like this (testcase.html in the attachment):

readystate: interactive
DOMContentLoaded
readystate: complete
load

So, many .mht files that rely on some JavaScript are broken.
Tested with Pale Moon 28.5.2 and MozArchiver 2.0.1.

testcase.zip

@Lootyhoof
Copy link
Owner

How was that .mht file produced? I just re-saved the .html as .mht and it worked fine.

Re-saved file, working as intended

@Siemenskun
Copy link
Author

Siemenskun commented Jun 24, 2019

Of course it looks like it works fine, because MozArchiver cuts off any included JavaScript while saving. Just look in the source code of your re-saved testcase.mht. Whole text in the textarea is just a plain text, not a script-generated.
I made my testcase.mht by hand, but it perfectly reproduce the issue you will encounter if you will open a .mht generated by UnMHT, IE or Opera with Presto engine.

@Lootyhoof
Copy link
Owner

Looking at this a bit more would suggest we do, in fact, purposely remove inline scripts: https://github.com/Lootyhoof/mozarchiver/blob/master/src/chrome/content/saving/ExactPersistParsedJob.js#L733

That said, I'm not entirely sure why this is. Other than not depending on potentially-online components I guess (i.e. something that depends on a server response).

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

No branches or pull requests

2 participants