FdoSecrets: implement unlock before search #6943
Conversation
Aetf
changed the title
|
Update: added guards for prompts to run concurrently. While haven't tested it yet, but I realize using a nested event loop for the blocking call isn't the best approach. What if another dbus call happens while KPXC sits in the nested loop? If the other call is for unrelated parts, it is probably fine because there won't be any other nesting. Actually, that's a problem in general: what will happen while one database is being unlocked asynchronously, and another client requests to unlock the same database. I need to think more about this. The solution is probably to remember database unlocking is in progress, and for any new requests, submit to the old prompt signal rather than create a new unlock dialog. Changing to WIP for now. |
Aetf
changed the title
|
Ready for review (or probably wait after #6915 so the history is cleaner) @droidmonkey |
|
So you're going with just an internal blocking prompt, without all the |
Yes. I view this as a workaround to increase compatibility. The proper fix should be done in the spec, either returning |
droidmonkey
force-pushed
the
feature/fdo-blocking-search
branch
from
a9516f0 to
e7d84ef
Compare
|
Rebased and squashed. Ready for review @Aetf ? |
|
Somehow I can't reproduce the test failure |
Aetf
force-pushed
the
feature/fdo-blocking-search
branch
from
e7d84ef to
485592e
Compare
|
Found the root cause of test failure. Ready to review. @droidmonkey |
Aetf
force-pushed
the
feature/fdo-blocking-search
branch
from
485592e to
ac77491
Compare
Codecov Report
@@ Coverage Diff @@
## develop #6943 +/- ##
===========================================
+ Coverage 63.61% 63.76% +0.15%
===========================================
Files 330 330
Lines 41807 41860 +53
===========================================
+ Hits 26595 26692 +97
+ Misses 15212 15168 -44
Continue to review full report at Codecov.
|
Fixes keepassxreboot#6942 and fixes keepassxreboot#4443 - Return number of deleted entries - Fix minor memory leak - FdoSecrets: make all prompt truly async per spec and update tests * the waited signal may already be emitted before calling spy.wait(), causing the test to fail. This commit checks the count before waiting. * check unlock result after waiting for signal - FdoSecrets: implement unlockBeforeSearch option - FdoSecrets: make search always work regardless of entry group searching settings, fixes keepassxreboot#6942 - FdoSecrets: cleanup gracefully even if some test failed - FdoSecrets: make it safe to call prompts concurrently - FdoSecrets: make sure in unit test we click on the correct dialog Note on the unit tests: objects are not deleted (due to deleteLater event not handled). So there may be multiple AccessControlDialog. But only one of it is visible and is the correctly one to click on. Before this change, a random one may be clicked on, causing the completed signal never be sent.
Aetf
force-pushed
the
feature/fdo-blocking-search
branch
from
ac77491 to
f09e97e
Compare
|
@droidmonkey updated this per comments. I also created #7041 to clean up deleteEntries. |
Thanks to the merge of PR#6943 [0] whenever a process runs a search while the keyring is locked the user will be prompted to unlock it. [0] keepassxreboot/keepassxc#6943
Thanks to the merge of PR#6943 [0] whenever a process runs a search while the keyring is locked the user will be prompted to unlock it. [0] keepassxreboot/keepassxc#6943
Thanks to the merge of PR#6943 [0] whenever a process runs a search while the keyring is locked the user will be prompted to unlock it. [0] keepassxreboot/keepassxc#6943
Thanks to the merge of PR#6943 [0] whenever a process runs a search while the keyring is locked the user will be prompted to unlock it. [0] keepassxreboot/keepassxc#6943
Thanks to the merge of PR#6943 [0] whenever a process runs a search while the keyring is locked the user will be prompted to unlock it. [0] keepassxreboot/keepassxc#6943
Thanks to the merge of PR#6943 [0] whenever a process runs a search while the keyring is locked the user will be prompted to unlock it. [0] keepassxreboot/keepassxc#6943
Thanks to the merge of PR#6943 [0] whenever a process runs a search while the keyring is locked the user will be prompted to unlock it. [0] keepassxreboot/keepassxc#6943
Thanks to the merge of PR#6943 [0] whenever a process runs a search while the keyring is locked the user will be prompted to unlock it. [0] keepassxreboot/keepassxc#6943
Thanks to the merge of PR#6943 [0] whenever a process runs a search while the keyring is locked the user will be prompted to unlock it. [0] keepassxreboot/keepassxc#6943
Thanks to the merge of PR#6943 [0] whenever a process runs a search while the keyring is locked the user will be prompted to unlock it. [0] keepassxreboot/keepassxc#6943
Thanks to the merge of PR#6943 [0] whenever a process runs a search while the keyring is locked the user will be prompted to unlock it. [0] keepassxreboot/keepassxc#6943
phoerious
added
pr: new feature
Resolves #4443. While at it, also fixes #6942.
Right now this is based on #6915. But I'll rebase once that is merged.
Screenshots
Testing strategy
Added unit test also tested manually
Type of change