1931641 - Cannot permanently bookmark a folder for saving a message / attachment

Status: RESOLVED MOVED

(Thunderbird :: Untriaged, defect)

Description

[Alain Knaff]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0

Steps to reproduce:

1. Rightclick on a message, and chose "Save As"
2. Navigate to a folder
3. Drag the folder from the main pane to the blue "New bookmark" entry in the lower left hand pane
4. Click open to save the message in that folder
5. Re-open the save dialog

Actual results:

After #3, the newly bookmarked folder appeared correctly in the lower left hand pane
After #5 (i.e. after re-opening the dialog), the new bookmark was gone.
Old bookmarks from many versions ago still show (as they should)

Expected results:

When dragging a folder to "New bookmark", it should stay bookmarked (until explicitly removed)

Comment 1

[Alain Knaff]

Using strace, I found out that those bookmarks are stored in file $HOME/.config/gtk-3.0/bookmarks

Manually adding the new folders into $HOME/.config/gtk-3.0/bookmarks and restarting thunderbird makes them appear.

strace shows that thunderbird only ever reads that file, but never writes to it.

It is not an issue of a corrupted file, as removing it, and removing the fallback file $HOME/.gtk-bookmarks too, restarting thunderbird, and then attempting to add a bookmark doesn't work either.

Comment 2

[Magnus Melin [:mkmelin]]

Sorry, what the OS provided bookmarking folder functionality of that dialog does is not controlled by Thunderbird. Thunderbird just ask the OS to pop up the dialog, and it's all out of our hands from there.

Comment 3

[Alain Knaff]

(In reply to Magnus Melin [:mkmelin] from comment #2)

Sorry, what the OS provided bookmarking folder functionality of that dialog does is not controlled by Thunderbird. Thunderbird just ask the OS to pop up the dialog, and it's all out of our hands from there.

That's a rather weird response. What should I, an end-user, do about this?

Other GTK applications that use bookmarks don't have the same issue, so I suppose it's a matter of firefox maybe not following the full protocol around that dialog? Possibly there is a final "commit" or "save" call that's firefox misses?

Comment 4

[Magnus Melin [:mkmelin]]

I don't know where the bug is. It could be in some GTK library. Or possibly in the code interacting with that code (that is code we inherit from Firefox). You can try latest Firefox (v149 or later) and see if you can reproduce there for some similar case. At any rate, it's code out of Thunderbird's control.

Comment 5

[Alain Knaff]

(In reply to Magnus Melin [:mkmelin] from comment #4)

I don't know where the bug is. It could be in some GTK library. Or possibly in the code interacting with that code (that is code we inherit from Firefox). You can try latest Firefox (v149 or later) and see if you can reproduce there for some similar case. At any rate, it's code out of Thunderbird's control.

I checked Firefox (140.8.0esr): the bug doesn't occur in Firefox, i.e. new bookmarded directories are indeed remembered.
Apparently, firefox and thunderbird share a bookmark file, and I do see the bookmark that I added via Firefox in Thunderbird.
However, I can still not add bookmarks in Thunderbird (also 140.8.0.esr) itself. They appear in the listing in the immediate, but disappear when I close and reopen the save dialog.

So there must be some subtle difference between how the code is used in Firefox, and how it is used in Thunderbird.

Nothing appears in Thunderbird's error-console, nor on stdout/stderr (view via .xesssion-errors)

Comment 6

[Alain Knaff]

On a different computer, I noticed that it works also in Thunderbird. Not sure what the difference between both is, both are same thunderbird version (148.8.0esr), and same distribution (Debian 13)

Comment 7

[Alain Knaff]

Found it.
A faulty apparmor file included by Debian, which had
owner @{HOME}/.config/gtk-3.0/bookmarks r,
instead of
owner @{HOME}/.config/gtk-3.0/bookmarks rw,

After changing this, it now works.

Sorry for having reported this issue here, rather than to the distribution.

Comment 8

[Alain Knaff]

Report as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1132362 to distribution