Confirming this behavior with a possible partial explanation.
Firefox sets images up differently on a drag than do the Chromium-based browsers. If we drag the image on this page from Firefox into the HTML editor BlueGriffon, the document source shows the image as a local temp file: file:///C:/{temp_path}/Temp/aiknxxbe.bmp
Whereas when we drag the image in from the Chromium browsers, it’s represented in the source as: https://i.imgur.com/WrkQMs8.jpg
That’s a hot link, live from the web. If we save that html file locally, every time we open it we’ll be consuming image bandwidth from imgur. Safe to say a hot linked image is not good game in a Scrivener document as its presence or absence is subject to the user’s web connection of a moment.
Pasting from the web into a Scrivener editor pane is always going to be unpredictable because of the scripts, elements and remote inclusions that can’t carry through to an RTF doc. Scriv needs to have HTML clipboard support, but keeping up with web display techniques will never be one of its core competencies. So I’d be surprised to see a fix for Chromium clipboards in V3. That Firefox delivers images more reliably into our projects will be valuable knowledge for advanced users. Great find Abby.
There are programs that make a specialty of grappling with whatever we may put on the clipboard, and representing it in a standardized way. OneNote is free to Windows users and has the added advantage of being able to capture and archive the contents of our smartphone’s clipboard as well as our PC’s.
So I’d recommend using the strongest tool for each job, pasting from the browser into OneNote, then pasting on from OneNote into Scrivener. And then deploying Scrivener for what it does best: managing writing projects of any complexity, refining our thoughts. compiling them into forms fit to be shared.
Thanks for your response. I’m trying to understand how pointing to a temp file can work while pointing to a remote file would require bandwidth to re-retrieve the photo each time…
If Scrivener always references the source file, does that mean if I copy/paste an image from Firefox that as soon as that temp file clears out, the image will no longer be available in Scrivener?
Wouldn’t scrivener always handle the clipboard contents by copying the actual image bits rather than just storing a pointer to the file/url?
Once the image is visible in a Scrivener RTF document, it abides within the project, and will not be subject to the web connection. Our challenge is getting it into the document in the first place. Firefox’s rendition of the clipboard, because it references local temp files, appears to deliver more actual images and fewer placeholders into the Scrivener doc than do the Chromium clipboards. I’m finding this to be true also when pasting into OneNote. I suppose it’s possible the difference could relate to browser cache settings but most likely it reflects the various browsers’ clipboard creation strategies.
Until the day comes when Scrivener can handle all browser clipboards equally well, I think we’re consigned to improvise with any tool in the drawer, including OneNote, Evernote and Firefox.
