Webarchive bug?

Not sure if this is an OS X thing or not.

I have several webarchives saved in my research folder. These were saved from a password protected site for my academic institution.

Normally, they display as expected (all original content is displayed and is the same as when viewed in Safari)

I am finding that, at times, when I try to display a webarchive in one side of a split pane, I’ll get an “access denied” message on the page background and the page frame has no content.
This is what typically happens if I have the page open too long in Safari and try to click on a link (I am auto-logged out).

Does Scrivener try to reload page content? I can view the webarchive properly in Safari and it never results in that behavior.

If I click on another webarchive (which displays normally) and then click on the original webarchive (or use the back button), it displays as expected.

Is there something I am missing?

If this doesn’t belong in the bugs forum, feel free to move it.


This is probably definitely outside of the Scrivener’s grasp. I’ve been wondering the same thing lately too. I’ve never worked much at all with web archives. I’d rather just store a local copy in good old directory/file format. I had thought that web archives took down everything they needed to be self-contained, but I think in some cases they do not. In the case of off-site content, those are not saved. So advertisement banners, frames, could be suspect. It might be that the site you are using has a tiered server setup, with part of the page in a frame, and that is why the webarchive is only archiving part of the page. Hopefully somebody who has more knowledge of just what these files are can provide a better answer.

It appears that the webarchive is archive all of the content, most of the time in Scrivener.

It always opens normally in Safari.

It will usually open normally in Scrivener and will always eventually display normally.

Strange stuff.

Hi, yes, as Amber says, I am afraid this is a little outside of Scrivener’s remit (even though it affects Scrivener). Scrivener just uses the standard Cocoa “web view”. All it does is then load the webarchive into the view, and tell it to redirect any links to the user’s default browser. Scrivener has nothing else to do with the webarchive, and I fully admit that I have no idea about any of this because I am no WebKit expert… Sorry.

And that is probably no more mysterious than: Because the page itself always looks normal in Safari. When Safari is handling the webarchive, it is accessing things that Scrivener does not have access to, such as browser cache and maybe even authentication tokens and some cookies.

Thanks for the replies.

It does indeed appear to be an OS X thing rather than a bug.