Make it so cookie crusher does NOT delete cookies from open tabs!

[publicsite]

Hi,

When I last used dooble, I had cookie crusher turned on and some tabs open and the cookies for the open tabs were being deleted (crushed).

I think the preferred behaviour would to be not to crush cookies from open tabs. Ie. only delete cookies when the tabs are closed; not when while they're open.

Looking forward to hearing back to you ... there may or may not be a small bounty attached to this issue.

Cheers,

Josh

[textbrowser]

Donations are not mandatory. :P This is an easy request. It will require a new option.

[textbrowser]

Never mind, it's impossible. Cookies are delivered asynchronously and without information pertaining to a page view. Suppose I have two tabs and both are accessing mit.edu. I will have received cookies from mit.edu and possibly other sites (third-party cookies). If I close mit.edu, I will have to inspect all other views for mit.edu as well as their active histories. For example, one page may be at google.com while the page also has mit.edu in its history. If I delete all mit.edu cookies, the page at google.com will have its mit.edu cookies purged. I will not know the true origins of the third-party cookies so I cannot delete those when a tab is closed.

[publicsite]

Hmm that's a shame ... At the moment I'm using "Cookie Autodelete" plugin with Ungoogled Chromium but would like to switch back to dooble as having to install the plugins for privacy is not ideal ... I don't know how Cookie Autodelete deal with the third party issue, but I guess the code varies across web browsers and may not be portable idk. :/

[textbrowser]

In Qt, cookies exist for a profile. The main profile being the session profile. There are cookie filters. I don't know of a method to isolate cookies to a URL. For example, https://doc.qt.io/qt-6/qwebenginecookiestore.html#deleteCookie requires a cookie object. It also allows for an optional URL. However, I would have to know which cookies are associated with a URL and iterate over them. Cookies don't really belong to tabs because several tabs may utilize the same cookies.

[publicsite]

Could you get it working with a 'disable third party cookies' option enabled? Reading this Cookie-AutoDelete/Cookie-AutoDelete#235 and looking at my browser settings suggest I'm simply blocking third party cookies. I know blocking third party cookies may not be the ideal, but it works OK for me re. browsing experience, generally speaking.

[textbrowser]

See Settings -> Privacy -> Block Third-Party Cookies.

[textbrowser]

I'm not understanding your last request. The ability to block 3rd-party cookies exists in Dooble.

[publicsite]

Ok. I can't find the code for it on github.

Basically, if "Settings -> Privacy -> Block Third-Party Cookies" is turned on. Then the problem you said about here:

Suppose I have two tabs and both are accessing mit.edu. I will have received cookies from mit.edu and possibly other sites (third-party cookies). If I close mit.edu, I will have to inspect all other views for mit.edu as well as their active histories. For example, one page may be at google.com while the page also has mit.edu in its history. If I delete all mit.edu cookies, the page at google.com will have its mit.edu cookies purged. I will not know the true origins of the third-party cookies so I cannot delete those when a tab is closed.

Is no longer as much of an issue when implementing "Make it so cookie crusher does NOT delete cookies from open tabs!".

You see what I mean?

Ie. you can do that on a domain basis if the option is ticked.

[textbrowser]

Oh, that's not completely true.

Suppose a tab's history stack is: github.com, mit.edu, codeberg.org. Suppose another tab includes codeberg.org in its history stack. If I close the first tab, I have to delete all github, mit, and codeberg cookies. Meanwhile the other tab is kind of broken. If I don't want to delete codeberg.org because other tabs are accessing it, than I have to inspect many things. There's also the thing with clearing history. If you clear your page histories, cookies remain.

It gets ugly.

[publicsite]

Suppose a tab's history stack is: github.com, mit.edu, codeberg.org. Suppose another tab includes codeberg.org in its history stack. If I close the first tab, I have to delete all github, mit, and codeberg cookies.

In this instance, you would NOT delete codeberg.org cookie as a tab would still be open.

But yes, it gets a bit ugly. Sorry if I sound too demanding.

[textbrowser]

If there was a direct relationship between cookies and pages, it would be easy. I suggest private windows.

[publicsite]

If there was a direct relationship between cookies and pages, it would be easy. I suggest private windows.

I didn't know about private windows. They look like they might be a possible option if they work similar to firefox describes here https://support.mozilla.org/en-US/kb/private-browsing-use-firefox-without-history idk. Incognito mode doesn't work for some reason logging into quite a few sites in ungoogled-chromium, this is why I use the plugins at the moment instead. I will have to test sometime.

[textbrowser]

Everything in a private window is discarded after the window is closed. Data are not written to disk during the existence of the window.

void dooble::prepare_private_web_engine_profile_settings(void) in dooble.cc is important.

[textbrowser]

As you can view and modify settings in a private window, settings are separate.

Cookies, favicons, visited sites, histories, caches, downloads, etc. are not recorded on the disk.

[textbrowser]

1. Open a private window.
2. Review .dooble as you browse in the private window.

You will not see files being changed in .dooble. If you modify settings, you will see the settings database with a new date.

[publicsite]

OK, the solution almost works, but not quite. Here's what I did.

1. Open Dooble, Normal Window
2. Turn Cookie Crusher On in Normal Window
3. Open Private Window
4. Turn Cookie Crusher Off in Private Window
5. Close Dooble (Private and Normal Window)
6. Open Dooble (Normal Window)
7. Check cookie crusher settings in Normal window.

Unfortunately turning cookie crusher off in Private Window, turns it off in Normal window upon going through the steps and checking at step 7.

Expected behaviour I think is to save normal window and private window cookie crusher settings seperately.

... A bit unfortunate the solution wasn't quite there. Possible you could get this route fixed?

[textbrowser]

A cookie window accessed from a private window will be denoted by a "privacy" icon in the cookie window's status bar. Changing settings in that private cookie window will not be retained because the window is considered temporary. These steps you list perhaps create a glitch. Anyway, the intent is that private cookie windows are private, including their settings.

[textbrowser]

Sometimes I introduce settings and forget about private windows. There are many complex interactions in Doovle and I don't review them all. Not that anyone else does. :P

[publicsite]

Ha, ok, but can you fix my glitch? :--)

[textbrowser]

Someday.

[publicsite]

bows hat

[textbrowser]

Perhaps tonight or tomorrow. Being a melancholy day.

[publicsite]

well that would be looovely. [but] don't be too harsh on yourself ... make sure you take it easy

[textbrowser]

Interesting are the discoveries of concepts when things are unrelated but become related through discussions.

[textbrowser]

Committed some corrections. Night!

[publicsite]

Thanks, I will recompile and test soon. Night.

[textbrowser]

:)

[publicsite]

Hrr. I tested. Unfortunately this is introducing a new glitch ...

Dooble is not saving the state (either at runtime, or in .dooble) of cookie crusher in the private window.

Appreciate your efforts,

Josh

[publicsite]

I did a bit of arduino on a breadboard once ( https://docs.arduino.cc/hacking/hardware/building-an-arduino-on-a-breadboard ) , but didn't get much futher with it than that. Have always had ideas, like LoRa and Audio Synths but electronics is not really my thing so much as computing. I saw your graphical coding. It reminds me of scratch programming language https://en.wikipedia.org/wiki/Scratch_(programming_language) . The Open University did something similar with an atmel custom board once. Will take a look at the link to those pis you gave, thanks for that btw. I know about not overrunning buffers in C just about, though some of the code I have written there are probably errors. I used to check with valgrind and/or gdb. I didn't know it was a problem so-much with graphical coding.

[textbrowser]

Glitch does not protect the designer from hazards. It produces whatever you ask it to produce.

[publicsite]

I understand the gist of most of your projects from the description (that is, w/o actually running the code), with the exception of Spot-On, which I'm not really sure what that's about.

[textbrowser]

Spot-On? It's the tree of life, of course. :D

[publicsite]

Maybe if I get time I run in a container idk.

[textbrowser]

Why a container? It's safe and open. It tells you everything it does. Too many options.

[publicsite]

I'm having a job to audit it is all.

[textbrowser]

Audit Spot-On? That'll take a long time. It's like writing it.

[publicsite]

I think I understand it a bit more now from inferrence. I don't mean a complete audit of course :P

[publicsite]

Can't get the spell checker to work in Dooble either. You will notice that I have spelt inference and many other words wrong too...

Do you have an IRC btw?

Totally abusing GH issues.

[textbrowser]

Did you select en_GB and press Apply?

[textbrowser]

No, I don't use IRC any more. I don't chat.

[publicsite]

Yeah. I select en_GB and hit apply. Perhaps I need dictionaries installed?

[textbrowser]

Yes.

qtwebengine_dictionaries must be accessible by Dooble and the Web engine. The directory's location is relative to the application.

[textbrowser]

https://doc.qt.io/qt-6/qtwebengine-features.html#spellchecker

[publicsite]

I have Dooble in /usr/bin at the moment. I will install libqtspell-qt5-1 and restart Dooble.

[textbrowser]

qtwebengine_dictionaries must be in the same directory as Dooble or you have to set one of the environment variables as described in the document.

[publicsite]

Hi spell checker now works, thanks.

#!/bin/sh
sudo apt-get install hunspell-en-gb qtwebengine5-dev-tools
sudo mkdir /usr/bin/qtwebengine_dictionaries
/usr/lib/qt5/bin/qwebengine_convert_dict /usr/share/hunspell/en_GB.dic en_GB.bdic
sudo mv en_GB.bdic /usr/bin/qtwebengine_dictionaries/

EDIT:

Dooble does this for you in the Makefile, there is a folder called qtwebengine_dictionaries in the dooble folder after building dooble, instead it is better to copy this into /usr/bin .

[textbrowser]

Wait!

[publicsite]

Wait wot? XD

[textbrowser]

[textbrowser]

New warning label. You'll also notice an answer to another of your questions from a recent discussion. Hint: which window.

[textbrowser]

One of my new habits is to transform software into living intelligence.

[textbrowser]

Which is much work.

[publicsite]

I think you have answered all of my questions thus far. :)

[textbrowser]

Location of .dooble is stated in the top-left.

[textbrowser]

More thinking.

[textbrowser]

I wonder if the dictionary files are read once at initialization and not after. So, if you introduce or remove a file, the engine will not realize the event.

[publicsite]

Hi spell checker now works, thanks.

#!/bin/sh
sudo apt-get install hunspell-en-gb qtwebengine5-dev-tools
sudo mkdir /usr/bin/qtwebengine_dictionaries
/usr/lib/qt5/bin/qwebengine_convert_dict /usr/share/hunspell/en_GB.dic en_GB.bdic
sudo mv en_GB.bdic /usr/bin/qtwebengine_dictionaries/

EDIT:

Dooble does this for you in the Makefile, there is a folder called qtwebengine_dictionaries in the dooble folder after building dooble, instead it is better to copy this into /usr/bin .

I updated that post so people reading would understand a bit better.

[textbrowser]

The menu item is a very primitive widget. Although it allows for tool tips, most often the tool tips cannot be actualized because of focus. One cannot describe a live reason for the cause of a menu item's sensitivity. Why is this menu action disabled? One doesn't know, it just is. Software is annoying. Living software is difficult yet beautiful. Reactions, events.