User Details
- User Since
- Dec 3 2025, 10:40 AM (5 w, 6 d)
- Availability
- Available
Yesterday
Mon, Jan 12
Fri, Jan 9
Thu, Jan 8
Addendum: I currently do not think we can do anything about this, except for documenting it.
I suppose you selected "Allow", then, and yes, that's enough to "fix" the problem. Chromium does remember the decision (unfortunately, it also remembers if you selected "Block", and some users are doubtlessly going to do so).
when do you see this precisely?
Wed, Jan 7
Mon, Jan 5
Mon, Dec 22
Observations (confirmation wanted):
- If no other gpgol-client Window is currently showing, the newly created window will show on top
- With the config window showing (but nothing else)
- clicking on reencrypt the first time will fail to bring the window to the front
- cancel it and click on reencrypt, again -> window comes to the front
- Similar observations when clicking on view/decrypt, reply, etc. for the first / second time.
- Hypothesis: Windows might become whitelisted depending on their title
Merged, manually (e63f7c1a62bd94594c0d7cd4326b94afc0e5fe71)
Should be doable your QStandardPath::GenericDataLocation . See also T7987
Fri, Dec 19
Thu, Dec 18
Wed, Dec 17
Tue, Dec 16
Mon, Dec 15
Partial / WIP fix: branch work/tfry/refresh_draft_list
There are actually two separate causes for this:
- For newly created drafts, the native client fails to keep track of their existence. It will thus only "find" them, when it is re-started.
- Beyond this, the only place where drafts are synced is the "info-fetched" command. This is sent in response to the "info" command, and that only gets sent when changing to a different email, or reconnection. Further, only reduced info (not drafts) is sent back to the web client, in case the message was already cached in the native client (WebsocketClient::info()).
Apparently, the relevant option appears to have been renamed in outlook:
Related to T7972 and T7726 . Currently it would be unclear, whether we should fall back to some other available native client.
Dec 11 2025
WebServer::processCommand, case Command::Register. When a web client connects, we send the mapping to both web client and native client. However, when a native client connects, we only send the mapping to the web client. We'd need both, here, too. However, we probably want to refactor both cases to use common code.
