Closed JBigglesworth closed 5 years ago
Indeed, the option does not exist because i was thinking it would a bit complicated to implement it in SingleFileZ (it's easier in SingleFile). However, I might have an idea to implement this option more easily. Stay tuned ;).
And it's done! I hope it will work as you expect.
Thanks for the extremely quick change.
I tried v0.2.65 out and the 'Save in background' option is now visible and can be toggled and is persistent across Firefox restarts etc but although the Windows 'Save As' dialog appears, it reverts back to the Downloads folder each time. (I'm left clicking the SingleFileZ icon each time up in the toolbar at the top right of Firefox.)
I created a new Firefox profile and installed only SingleFileZ to try and isolate the problem but the problem still occurred. I did see something similar quite a while ago with SingleFile but it seemed to come good over time, possibly a newer version of Firefox, SingleFile and/or other extension(s)?
I'm sure it's probably a quirky bug - probably trivial compared to the effort you must have put in to getting page scraping compatibility issues nutted out but it would be great if you could get to the bottom of it!
Indeed... I tested the fix only in Firefox Nightly build and it looks like it's not working as expected in the stable version of Firefox. It works fine in Firefox 71 (Developer Edition). I was not able to find a workaround in Firefox 70.
I've pondered what it would take to get into Firefox extensions but, from what you're indicating, it sounds like the APIs are a bit nebulous/ill-defined!
I might try out Firefox 71 even though it's less stable if I'm able to install it in parallel with 70.0.1.
Thanks for checking out the problem.
@JBigglesworth this issue should be fixed in the new version 0.3.0 I just published.
Just tried it (Windows 10 Pro x64, Firefox 70.0.0.1 & SingleFileZ 0.3.0) but, unfortunately, it still doesn't work. I then tried SingleFile 1.13.12 and it also doesn't work.
As a comparison, I tried Save Page WE (by 'DW-dev') and it works.
With SingleFile & SingleFileZ I have the 'Save in background' and 'Open Save As' options enabled. Is there anything else that should be enabled or disabled to get it to use the previously used save directory?
You have to disable "Save pages in background" to save the last location.
Disabling "Save pages in background" fixed the problem. Thanks! (I'm sure I checked this option based on help notes somewhere to do with the original SingleFile but it was some time ago that I read and remembered this requirement. - Maybe I have had it wrong for quite some time and have wasted both our time! - Sorry!)
You're welcome :)
I'm probably taking a bit of liberty in extending this thread but what are your thoughts on the ease/interest/possibility of extending SingleFileZ to handle the following usage?
I'm frequently in research mode and may be trying to throw numerous saved web pages into various folders (eg: Explorer opened alongside browser) to keep track of what I've traversed. (Some of these folders exist from previous sessions and some are created as I go.) What really seems neat what would be to be able to drag and drop pages directly into these folders (eg drag the page perhaps by it's background?) with the option to additionally rename and/or create a sub folder on the fly.
(I've found relying on URL links and 'Internet Archive' to be in the "not there when you need it" category leading to much frustration knowing that you've either seen it somewhere and can't remember where or it's no longer accessible!)
Is this something that is of interest to you and, from your perspective, is it an incremental or a major effort? - Either way, it would be interesting to get your thoughts on the idea.
Regards, Pete
Thanks for the suggestion. Technically, it's not complicated to implement. However, I did some tests and I can conclude that this feature would work only in Chrome (see here for the issue on Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=570164). The second problem is the security. If I implemented this feature, it could be dangerous in terms of privacy because the website could intercept the saved page when doing the drag and drop and read contents that it could not read usually, e.g. the content of frames hosted on other domains.
Some further thoughts/observations: Firefox seems to have no idea as to how to handle an attempt to drag the background but it does handle dragging a selection of text, formatting/style & images that can be dropped on an appropriate drop site (eg Word) and hence, up to the drop site to do the work that SingleFile does it terms of saving it into a html file with embedded additions such as infobar. Perhaps what I'm thinking of is better thought of as bypassing the final stages of SingleFile and presenting a drag site that represents the newly created file and hence can be dragged into something like Windows File Manager. - Either that or having SingleFile intercept drags of the Firefox address bar (which can be used to create URL links/bookmarks) and converting the transfer object from a URL string to a file object. Are either of these permutations feasible?
Perhaps what I'm thinking of is better thought of as bypassing the final stages of SingleFile and presenting a drag site that represents the newly created file and hence can be dragged into something like Windows File Manager. -
That's actually what I implemented. Firefox can handle the drag of the background. Technically speaking, I attached to the document of the page an event handler that was detecting the "drag" event. Then I passed as data of the event the entire content of the saved page and the filename, as described here. The drag always works but not the drop, when using Firefox.
Either that or having SingleFile intercept drags of the Firefox address bar (which can be used to create URL links/bookmarks) and converting the transfer object from a URL string to a file object.
I don't think there's an API to detect drags of the address bar. But the problem would be the same, the drop would not work.
1- I'll code a special version of SingleFileZ that I will post here allowing you to see what happens. 2- That's "funny", that's exactly what I'm thinking about these last days, cf. https://github.com/gildas-lormeau/SingleFile/issues/311 (and https://github.com/gildas-lormeau/SingleFile/issues/312). It will probably apply to SingleFileZ too, but it's not under the radar yet. 3 - That's probably a solution indeed but this requires some substantial additional work especially if I decided to implement native apps instead of let's say an Electron app for the "drop site". 4- No problem, I may implement this feature anyway for Chrome users in SingleFile via the annotation editor. There is no security issue in the annotation editor.
Here are the special builds for each browsers. You have to unzip the files and install the extensions manually as described here:
Use it as usual, it won't download a file but let you drag and drop the background of the page. In Chromium-based browsers, this will work.
Links:
I've just had a foray into the world of browser development! I ran up SingleFileZ in both Chrome and Firefox and have a better sense of what it's all about. It does seem that conflicting goals and ideologies seem to be major hurdles for a seemingly simple extension to an extension - pardon the pun! Raises the question as to whether there's merit in developing a generic native Windows/Linux/MacOS platform/framework to enable extension authors to jump out of the browser environment when helpful. I can't help feel that Mozilla seems to be closing in and tightening control of 'their' software; - is closing it the next step?
Actually, that's something I anticipated when I rewrote SingleFile from scratch. I re-designed it to make the business logic code totally independent from the extension code. That's why SingleFile can today run outside of the extension world like the command line interface. In this case, it relies on a testing framework to inject itself in the browser (it can also run without any browser if necessary). Integrating it into an Electron application would also be quite easy. Finally, a GitHub contributor proved it was possible to run it into WebKit. So, you don't have to worry ;).
I don't think Mozilla will stop supporting extensions in the future. The case of SingleFile is a bit particular and shows, from my point of view, their rules do not take into account the problem of forked code. That's a (important) detail but it does not mean they begin to distant themselves from web extensions. I think it just means they want to make to review process more efficient.
Thanks for the tip re Electron. I have some serious reading to do.
My background is best described as aligned to C#/F#/Rust/C++/Assembler. Given my intense (and growing) dissatisfaction with Microsoft and their like, I've migrated to the Linux/BSD world and am trying to get a sense of using web technologies to replace distributed 'desktop' scenarios that are not controlled/owned by proprietary interests. My one major concern is writing code using Javascript. I'm not adverse to it as an intermediate language but it just doesn't seem to be quite yet in terms of a rich development/management/support ecosystem. This is not so much saying I want an 'X to Javascript Converter' (which may be a necessary sub-requirement), but a philosophical thought on which source environment, from your perspective, would be a good feed into web development utilizing Electron based on your expertise/experience?
That's hard to say. I would say that the most important thing IMHO is to find a topic that motivates you. It can be anything like porting a useful CLI tool into a beautiful UI or coding a game, or creating your own "super-browser". Electron and the Web APIs will allow you to code almost every app you could imagine % the efficiency of a JS VM. The biggest advantage of these technologies is the very good portability of the code.
First: - Great extension, highly compatible with all manner of pages.
Problem: (Windows 10 Pro, using recent versions of Firefox and SingleFileZ) The 'Save Pages in the background' option seems to be missing.
(In SingleFile, this option appears under the 'Misc' options. In SingleFileZ it is referred to by the help for File name | 'Open the "Save As" dialog to confirm the file name' but the option seems to be missing?)
Usage: In SingleFile, I found I had to enable the 'Save in background' option to get the save dialog to default to the last used folder rather than reverting to the Downloads folder (with or without the "File name | 'Open the "Save As" dialog to confirm the file name'" option being set).
I find this tracking of last used folder is very useful, is this a design change (sad!) or an error (less sad?) that can be addressed?
A long ask given your limited time and resources for a volunteer effort but is it possible to add some more info to guide new users to this somewhat hidden functionality?