Feature Request: save scroll position

[Nico04]

First I'd like to thank you for this plugin, I use it everyday, it's very handy !

I'd love that the plugin also save the tab's scoll position.

I've seen this feature in this issue : https://github.com/ReDEnergy/SessionSync/issues/40

Does this mean it will be implemented ?

[ReDEnergy]

Hi. Well, it means that I would like to have it implemented but I'm not 100% sure how if I can do it. The main problem is that I have no proper way of storing additional data alongside a bookmark (because the API is not available in WebExtensions and probably will never be) . I can do that pretty easy for History sessions since they are saved in addon-storage but I don't really want to mislead user into thinking that would be the same for bookmark storage. I did this with pined tabs and it creates confusion, so unless I find a good way to implement the functionality for both I won't deliver it only for a part of the addon. The main problem that I don't like about addon storage is that it is instantly deleted by Firefox when the addon is unsinstalled/reinstalled (or sometimes god knows why) and I can't guarantee that strange things can't happen with that part of data. Since I don't really want to split data between bookmark and addon-storage because of this I have to come up a different solution. Sadly I can't say for sure when this feature will be delivered.

[Nico04]

Can't you use addon storage as you said just for additionnal data like scroll position or history ? Because for me if the data is lost it's not a big deal as it's additionnal data. The main data (tab url) is still stored in the bookmark like today.

[ReDEnergy]

Using "tag" as storage is a bad idea ? For instance you add a tag "scroll_456" or "scroll_789" ?

Well... it might be possible and not such a bad idea... but sadly Mozilla removed any possibility to add additional data to a bookmark. Although you can add tag or even keywords using the browser interface the API is extremely limited and only allows you to add URL and TITLE... just that, nothing more. In the older version of the API I had everything implemented using bookmark annotations (additional data) but we all know that they crippled the new addon API in such a way because of Chrome... very "smart" decision what can I say... I think is clear... I will try to find a way around this. I have a solution to add additional data to each URL but I'm not really sure if users will be ok with this or not... What I ca do is this. For example let's say we have this link: https://addons.mozilla.org/ro/firefox/ The W3C documentation actually allows you to add additional data to a certain URL by encoding them in GET parameters... so I ca do something like this https://addons.mozilla.org/ro/firefox/?something=data&scroll=500&and_so_on=true So by doing this... I can make sure the link will continue to work as it should, and all the data will be saved with the bookmark. The only thing I'm not sure right now is if there's any chance to break the URL page:

• although by standard things should work... not 100% percent if a certain site might have problem because of what data I add into the link because that data will be sent to the site when you access the link
• not very sure if users will accept this (probably should be optional and if you want to use these feature then it means your ok)

[Nico04]

It's a shame the api is so limited... So yeah, you'll just have to find a workaround. Maybe instead of using the url, which is the key data here, you can use the title? For instance, if the original 📄page title is "Github", you would modify it this way : "Github | scroll=568,data=...,..." And yes it can be optional so it doesn't disturb users that doesn't need that. And for the one that need it, like me, I guess the title isn't that important as we just load the session and when the page is loaded the real title will be set.

[Nico04]

Can't you use addon storage as you said just for additionnal data like scroll position or history ? Because for me if the data is lost it's not a big deal as it's additionnal data. The main data (tab url) is still stored in the bookmark like today.

What about this?

[ReDEnergy]

I can do that... but most probably I wont. Few users really read the tutorial or full description of the addon. Most just expect things to work out of the box and that there are no "special" conditions. I simply hate when I see 1-2 stars rating just because people expected it to work somehow and then suddenly they lost History. Not really sure what happend but I received quite a few complains and bad reviews because of the unreliable addon-storage. As much as I try to do things the proper way, Firefox has it's way to kill things randomly and right now I don't really have confidence that by providing that data won't create the false impression that things are saved and will always be. I prefer to chose a solution that I know it's save, and won't have the same issues, because even if for you losing that additional data isn't such a big deal, the same can't be said for any other users that will put his trust on having that data after be it 1 week, 1 month or even 1 years. Sadly, offering something that mostly works is worse than not providing the feature at all. At least when it comes to how users react.

For me as a developer, I put my free time into this addon only because other people seem to like it and find it useful and at the same time it really motivates me when I receive good feedback. Unreasonably bad feedback helps at nothing. I really care about this project but I if I start to get to much negative feedback on it I will just assume that I waste my time. So in a sense... after the Auto-History saving fiasco (a feature requested by some users) based on addon storage that crates most of the problmes, I try to make sure that any additional feature I deliver, has a good overall quality and stability so that the same story doesn't happen again. And that might mean that some feature will take longer to be launched while others because of the limited API might never be implemented or even if they are will be activated on demand by users to make sure they really understand that some things are still experimental. Now, the problem is that if I take a certain decision is really hard to go back. If I put for example the data into URL or into the title, it will really be hard to change it in the feature and supporting the addon will become harder and harder. From a developer point of view I have to make sure that a certain decision I take I can continue to support if for a long time because I have no idea when a users might want to use the addon for interacting with what he saved 4 years. Ideally every feature I provide should still work even 10 years from know.

Yes, there are always some exception that we can consider are clearly not critical and probably nobody will ever complain about them if some feature will suddenly stop working. I suppose scroll position can be considered on of them. I mean, I think it might be really exaggerated to have angry people messaging me that certain saved bookmarks are not auto-scrolled where they should be... Or who knows.

Again, this feature I'm also interested in it, but not 100% sure I can deliver it very fast, because any kind of additional data that I add, will affect the overall performance of the addon (at least when saving/restoring) and I have to make sure things will not slow down too much.

[Nico04]

Thanks for this detailed explanation. Honestly I truly understand your point of view. It's a matter of overall quality with few features vs a lot a features with lower overall quality. And yes I'm sure most people doesn't go to settings and read, but for advanced users, options that are clearly stated as experimental in the settings, still look as a good idea to me, because for people that doesn't care it will be disabled, so they cannot complain.

I'd loved to have those two features, even if additional data isn't reliable, but I'll respect your choice in any case 😉