from session restore, save list of pages and urls as text file or html file.
Categories
(Firefox :: Session Restore, enhancement, P3)
Tracking
()
People
(Reporter: ray, Unassigned)
References
Details
My firefox app is having problems and crashed. So, here I am at the session restore window.
Perhaps I do not want to load all of those. Perhaps I want to copy down a list of the pages (with urls) that I had open. I wonder if ff has a list of the pages I had open, with the urls....
Hm. There is the list, right there. Maybe I can save that list, as a list of pages and urls. But to get to it as a list .. of pages with urls.... Nope. Cannot do it. I can see it, but I cannot get to the list that I can see.
Why not?
Comment 1•1 year ago
|
||
Need-info myself as a reminder to come back to this. In an ideal world, no user ever sees about:sessionrestore, but in the cases where they do we present them with a list of tabs to restore and any tab that gets un-checked is essentially lost forever. I can understand the desire to want to capture at least the list or page URLs at this point in the session restore flow.
Thanks for the comment. FYI, I am planning to look at the code to see if I can create a basic implementation. I am familiar with the dev process, but it has been a while. I would be open to any suggestions here. No rush.
fyi, I can see that source/browser/components/sessionstore/content/aboutSessionRestore.xhtml contains, or refers to, this element:
<!-- holds the session data for when the tab is closed -->
<input type="text" id="sessionData" hidden="true"/>
So, how does one get to this? For myself, the first thing I can do is grab the json therein and put it into a file under /tmp, unconditionally. At least then, I could get to the lists.
Then I would look at a button, perhaps to the left of the 'Start New Session' button for "Save Session Links" or some such. Then there would have to be a picker for the directory. It would be good to not have to have the picker. There could be a default directory (such as /tmp) in about:config, so that it would be settable? I am not sure what would be acceptable here. Like I said, a picker is obvious but a pain in the rear. Can it be avoided?
It is tempting to suggest an 'about:sessionrestorehtml' that gives you the list in a view where the urls are all visible and copyable. Because, you know, we have a page now which contains all the urls. But we are given a list that is not expandable, that only shows you the titles and not the urls and only allows you to select one item at a time. And copy is disabled! All of this is just lame. Perhaps this list can just be replaced with a more functional list and then none of this extra stuff is necessary.
Comment 4•1 year ago
|
||
(In reply to Ray Kiddy from comment #3)
So, how does one get to this? For myself, the first thing I can do is grab the json therein and put it into a file under /tmp, unconditionally. At least then, I could get to the lists.
The full session data is in a gStateObject global. The selections from the page are used to update the gStateObject, removing tabs and windows from that session object before restoring it. If you just want a list of urls, you can iterate over gStateObject.windows to get each tab, and each tab should have a .url property. You can inspect gStateObject in the console or debugger to see how its structured.
Then I would look at a button, perhaps to the left of the 'Start New Session' button for "Save Session Links" or some such. Then there would have to be a picker for the directory. It would be good to not have to have the picker. There could be a default directory (such as /tmp) in about:config, so that it would be settable? I am not sure what would be acceptable here. Like I said, a picker is obvious but a pain in the rear. Can it be avoided?
If we're proposing to add a button here, I think I would prefer a copy to clipboard button, that puts the list of urls on the clipboard, leaving the user to decide where to save it and avoid the file picker entirely with all the complexity of default locations for each platform. Also, this data normally lives in the user's profile directory. If we save it elsewhere, there is some risk of leaking personal information unexpectedly. The clipboard is ephemeral and asks the user to explicitly decide there and then what to do with it or risk losing it.
It is tempting to suggest an 'about:sessionrestorehtml' that gives you the list in a view where the urls are all visible and copyable. Because, you know, we have a page now which contains all the urls. But we are given a list that is not expandable, that only shows you the titles and not the urls and only allows you to select one item at a time. And copy is disabled! All of this is just lame. Perhaps this list can just be replaced with a more functional list and then none of this extra stuff is necessary.
Yeah I think that's fair. We used a xul:tree control for this way back in the day, and its maybe not the best choice. A different implementation could easily toggle between title and url, make the whole list copyable, etc etc. We have new components for representing lists of tabs in Firefox View that could probably be put to use here. But doing a rewrite of this page will likely only happen in the context of a larger project, such as bug 1625831 or bug 1873249.
Thanks for the follow-up. It appears to give me enough to start.
Description
•