Cookies file randomly reset

[fanglingsu]

#235 seems still exists on some systems. So that the cookies file is cleared on cuncurrent access.

[rudism]

This is very noticeable for me when i've got a couple different windows open on cookie-heavy websites (browsing Amazon and Playstation Store simultaneously was almost unusable to me, with cookie file being wiped every few minutes).

vimb 3.10 on arch linux

[fanglingsu]

@rudism I think we can't fix this issue in vimb. In fact there is no cookie logic in vimb except of giving the file path to webkit and saying that webkit should write the data as plain text. Webkit should manage file locking right.
If I've some spare time I'll try to enforce some concurrent writes to the cookie file with some automated tests.

[rudism]

Off the top of my head, the only idea I can think of would be to add cookie management to vimb where each process gets its own webkit cookie file initialized from some shared database, then merges any changes from its file back into the shared database when the process exits. Would probably not be a simple thing to implement.

[subsetpark]

This issue was encountered in suckless surf as well. The way they resolved it was by using webkit's sqlite-based cookies, rather than the cookie file.

Here's a link to the commit in my fork of surf, with that feature enabled: subsetpark/surf@7ad5918#diff-635f306d489ba706e517a82c01ff6116R1134

Hopefully this can be applied to vimb as well - this issue is what's keeping me from using it as my full-time browser!

[rudism]

I'm running with this really basic patch now and everything seems to be working (though I haven't really done any multi-process cookie-heavy browsing yet). @fanglingsu was there a reasoning behind using webkit's text format instead of sqlite in the first place?

[subsetpark]

Pretty sure it's because vimb uses external tools like curl to manage downloading files, and they require a flat cookie file. That's why the rest of the commit in the patch that I linked is about using the built-in webkit downloader as well (which I actually prefer to curl anyway)

[fanglingsu]

@subsetpark you are right. I like txt files and in the webkit1 version we could spawn curl for downloading or doing other stuff (runnung shell commands) using this cookie file. I like the text format because it's easy to read (need this often at work developing webapplications) and to alter. I don't personally use external downloaders, but there where some users asking for the ability to use external downloaders. So using text was a way to allow other tools to pick up an authenticated session. But this did not work very well, because session cookies would not be written to the file.
For the webkit1 version we turned session cookies into cookie that would be written to the cookies file. This is not possible with webkit2 anymore so I think we should give the sqlite a try.

[fanglingsu]

@rudism Thank you for the hint. I don't like sqlite, but if this might avoid cookie file clearance, I'll give it a try.

[fanglingsu]

@subsetpark Your download manager patch to surf looks good. But I'm not sure if these download information would take to much room on smaller windows in case multiple downloads are started.

[mlopes]

The session seems to persist now even after having multiple instances on the same session and restarting vimb. 👍

[fanglingsu]

@mlopes Nice to hear that.