[NB] Apparent issues with Research web pages and Scrivener iOS

I hope I haven’t missed some previous report or reply on this.

I’m trying out web page abilities with the Beta latest.

  • If I’ve imported a web page on the Windows beta, I get only its title on iOS – a blank page ensues for content
  • if I import a web page on iOS itself, that succeeds, but then, I get just a link on the Windows beta
  • the link on Windows beta invites to click it for external viewer. I don’t want this, but try, and nothing happens

Hoping this is an area planned to be smooth and mutually compatible, just not implemented yet.

I did try the 1.0 Windows Scrivener, and then was reminded of all the mht/pdf hooha – none of which liked to work either, so tongue only slightly in cheek, lots of opportunity here.

Windows is very latest Win10 with ‘April’ upgrade
iOS is iPad2, which will only ever run iOS 9.3.5, the last and latest for it

For the time being, I can convert any of my own needs to pdf, but hoping this will work as above smoothly also for journalist friend’s shiny new ios11+ iPad I was actually checking this out for…


Well, a postscript on this one also, once I get it on the right message…

I just tried actually using a temporary workaround until this can get fixed, but not really soap there.

  • printed web page on Windows into pdf using built-in Microsoft pdf printer, which allways works nicely itself
  • where I printed to was a separated folder in Dropbox, so it would be present for Scrivener iOS
  • the link worked, and the pdf appeared in iOS Research folder, once synchronized
  • but – there’s no ability to select anything except a page there. Not text, not pictures. So really this is of quite limited usefulness, whether for me or my research-quick to published story journalist pal.

and, it doesn’t solve the reverse problem at all, that the Windows Beta doesn’t show the web pages Scrivener iOS nicely does import…

I’ll stop now, just best wishes for solving and smoothness :slight_smile:


This is down to a platform difference in the way webpages are saved. macOS and iOS use Apple’s webarchive format, which Windows does not support. (I’m not aware of any program on Windows that can view the webarchive format other than Safari, though there may be some.) Windows uses Microsoft’s MHT format for saving complete webpages, which can be opened in Internet Explorer, Chrome, and some other browsers with the proper add-on (Firefox can, for instance, but I believe needs to have the extension installed). Scrivener on Windows is able to load webpages it imports as MHT (or files saved externally as .mht or .mhtml and imported) but cannot load pages imported directly on iOS or macOS and vice versa.

As such, if you’re working cross-platform, it’s best to save webpages in the PDF format and then import that. Alternatively, if you don’t need to archive the page, you could use bookmarks to simply link to the site.

Hmm, thanks, Jennifer, that all makes quite good sense. And yes, platforms aren’t going to use each others’ archive formats, at least until many more cows come home.

I think though that I was expecting Scrivener to work around this, and became surprised it didn’t.

It seems a very good workaround would be to use the page link and just download the page, if the archive format wasn’t suitable. With increasing bandwidths coming along these days, it should often be quite transparent.

It’s not going to work when offline, but then a simple unavailable and why message can fill the edit block.

If you think people might not always want this behavior, configuration, no?

The funny thing is that I seem to remember Scrivener used to have an option to just load the page from the web, for Research. Maybe I remember wrong.

But anyway, to have it do so when it needs to and can seems quite valuable?

(getting into doing intense things with Scrivener again…)

Importing a web page into the binder will save the webpage in the archive format, and that saved page is part of the project folder and loaded in the binder. To simply link to the page, rather than importing it, you can drag the URL to the document or project bookmarks in the inspector (or use the Add External Bookmark option from the ellipsis button in the bookmark header). In Scrivener 3, you can view linked pages directly in the inspector, as well as choosing to open them in the editor. If you want a separate entry in the binder for the page, you can create a dummy document with the title, then add the link to that document’s bookmarks.

Jennifer, thanks. Again that’s comprehensive and also pre-understood.

Here’s the thing,.

  • you have a great system for using archives
  • this is particularly good for mobile platforms like iOS, which may not always be connected
  • thus the natural move is to put the reference in Research as an archive
  • then, though, it doesn’t open when back on Windows

This is why I think it would be a great feature that the reference did indeed open, directly on the web page, whenever the archive can’t be read

  • for extra points, what about storing both archives, as they become available, so that the Scrivener project gains speed and offline portability as each platform is exercised?

This is one of those areas where abilities can be internally combined, so that the great feature abilities of Scrivener get to be smooth, and transparent.

And thus far more likely my journalist friend etc. can take advantage. That’s the reason to do it, no?


Capturing the archive at the time the reference is made is often the desired behavior, because you want a point-in-time archive. Web pages change without warning, and if the user’s purpose is to capture a specific set of data, opening to a live site may defeat that purpose.

n.b. I need to speak with your cat…

Devin, what I’m suggesting goes along with what you say – doesn’t go against it.

I’m saying:

  • capture the archive every time Scrivener can
  • use the archive every time Scrivener can
  • when at first archive isn’t present, go to the web and capture it for that platform
  • save the fresh type of archive captured, beside any current but unopenable kind
  • use whichever archive is a fit for the platform, next time Scrivener wants to display it

Hoping that’s clear? It’s just software doing for you, more than requiring from you…


Even if it were technically feasible, I don’t know that it would be desirable to have Scrivener automatically downloading archives in the background and bloating the project with extra files. And as pointed out, the page may be different when accessed on the second platform than when originally accessed, so you could end up looking at subtly different material on your different platforms without realising.

For webpages imported and viewed on the desktop platforms, the original URL is displayed in the editor footer, so accessing the current version of the page is as simple as clicking that link. At the moment that is not possible with pages imported on iOS, because there is no record of the original URL. I’m fairly sure this is down to the imitations of the toolkit on iOS, but I’ve brought it up with Keith in case there is a way around it, so that we can have the same easy URL accessibility for iOS-imported webarchives as macOS.

In the meantime, if you want to stick with the web archive formats, copying and pasting the URL into the document notes would give you access to the current version of the page when on another platform. Otherwise, saving and importing the webpages as PDFs or as a text format (or just copying and pasting!) will keep the archived version accessible on all platforms.

Jennifer, that’s a very good idea and short-term workaround, to have the link put on screen when the available archive can’t be read by the Windows or iOS platform.

For the Mac also, when the archive might have come from Windows.

The technical side of what I propose to get improvement is very easy – not a problem of feasibility am sure Keith might agree.

To answer your performance thought, I’d suggest that it’s natural that the web page only be downloaded when/if you click on a Research item – and only of course when the archive isn’t usable. So this shouldn’t be a problem; rather a quite convenient feature, as you don’t then have to take extra steps yourself.

As far as ‘bloating’, it’s only two formats we’re talking about, comparable , and they’ll only be downloaded or synchronized the once and if there’s need. Bandwidth is ample these days, or syncing wouldn’t be feasible, not so?

The question of updates on the source web page would get us into several other matters – and pages seldom do of the type for reference anyway, would think.

The main thing, it seems to me, is the solidity, dependability, and smoothness factor to be gained.

To put it on the point, persons such as my journalist friend will be quite taken aback if their reference materials disappear. That’s how I first confronted this issue.

It seems any and all the things we know we could do to prevent that are to the good. And your provide-the-link suggestion is again a very useful first step. The next suggested step will make things a lot smoother, and make them work when using the handheld in transit, on the plane, just not able to connect, which seems quite important, doesn’t it?

And no, we can’t make it perfect, but can do a lot… Please see if Keith doesn’t agree, would you?


You’re making a lot of assumptions about how web archives are used that aren’t warranted given the wide user base in Scrivener and the number of different ways in which people use them, in order to promote a scenario that is going to continuously violate the Principle of Least Astonishment.

Ah, Devin…

Not sure why you keep log-rolling here – I would feel it’s not protecting anyone as you seem to think?

As for principles of least astonishment, I would have thought those include not getting a blank screen when you try to use a reference that has previously worked fine – on the original platform.

I think that journalist example is apropos, but it isn’t different for a writer of any kind gone portable on a trip, a retreat, or just hoping to lie back on the couch with an iPad.

Transparency is the virtue I’m after – simplicity for the user, and that is all.


The original URL is already available as a link in the footer on both macOS and Windows for webpages imported on either of those platforms. At the moment, pages imported on iOS do not record the URL information (so it therefore cannot be displayed on Windows or macOS) and iOS likewise doesn’t display the original URL of imported pages, but Keith has added this for the next iOS update, so that will work also.

The goal of two versions of the page can therefore be achieved already with very little work. Right-click the link and copy it, then select Import > Web Page…, paste the link, and import it. Alternatively, click the link to load it in an external browser (thereby letting you double-check that the link is still good and something you even want to import), then drag the page into the binder to import it.

It is a few clicks of manual effort, but I think that’s preferable to having Scrivener handle it all in the background so that you aren’t even aware it’s happened. What if the page has been updated with fact corrections, but you don’t notice it’s not identical to the other? You’ll be mixing up your references each time you switch platforms. And speaking of references–what date then do you give in your bibliography for when the page was accessed? (What date is Scrivener supposed to show in the inspector?–it can’t have two separate “created” dates for the same binder entry.) Or what if the original URL no longer even exists as such, and you’re just downloading some spammer page from whoever’s bought out the domain?

One way or another, there are a lot of assumptions being made. Bear in mind too that an automatic download would still only work when there was an internet connection, so it doesn’t fix the suggested problem of discovering your archives aren’t a compatible format when you’re disconnected. For that you’re still going to need to transfer to the other platform and download all the pages before getting on the plane.

As far as the transparency of the problem, Keith has also added an “Unknown Web Archive Format” text to the editor display when iOS or macOS tries to load a Windows-imported file, and we’ll do the same on Windows for the macOS/iOS webarchives. It should then be a simple matter for the user to re-import the webpage if desired, or just wait until returning to the other platform.

Jennifer, thank you. A lot of good thinking there.

And you are fortunate, since I put all my energy for the late night into that other reply :slight_smile:

What you say here sounds reasonably encompassing, and reasonably reasonable. I do certainly understand.

Getting those links and brief explains up will solve the blank screen-what happend problem. Particularly if using the link just engages the on-platform mechanism to save its archive.

Indeed the alternate archive formats would need one to remember to load both before going on an untethered trek or relax. I did realize that, and you are not going to get around it without a package to produce the extra format on either platform, which is probably not available.

Given producing the archive via link on a so-far unprovided project, I think you’d have nearly everything you’d need for someone thoughtful enough on an occasion to prepare – and having them comfortable again once they’ve gotten to the internet.

I’d just like to say I don’t feel to be too concerned about any potential difference in website content over time. Articles themselves don’t often change; unless we are talking about online catalogs. (I still have an amount to do with CMS - content management). Cases of either you’d have to deal with anyway, perhaps via last-minute fact-checking on tricky journalism, such as after plane landed, or the next morning occurred.

So, as just done on the screen visibilityissues, I’ll hope to have left you and the team at least a path to consider on your own time and own way. And good fortune with what you decide, or when.

All the best,

it is late…