Fix locking database when password generator is triggered from browser extension #9821
Conversation
| @@ -506,6 +506,8 @@ void BrowserService::showPasswordGenerator(const KeyPairMessage& keyPairMessage) | |||
| if (!m_passwordGenerator) { | |||
| m_passwordGenerator.reset(PasswordGeneratorWidget::popupGenerator(m_currentDatabaseWidget)); | |||
|
|
|||
| connect(m_currentDatabaseWidget, SIGNAL(databaseLockRequested()), m_passwordGenerator.data(), SIGNAL(closed())); | |||
There was a problem hiding this comment.
This works but it should really call a slot like hide or reject.
There was a problem hiding this comment.
Is there even those slots in that class? Everything just signals closed().
There was a problem hiding this comment.
Generally, you never want to rely on the fact that a signal is listened to. We happen to listen to it internally to the password generator, but that's not necessarily the case. If you call the hide slot it should emit the closed signal which then executes the rest of the sequence.
There was a problem hiding this comment.
This is best to done to the other PR. We'll have to make sure the m_passwordGeneratorRequested is set to false if we use hide() and the pointer is destroyed. Just changing the SIGNAL(closed()) to SLOT(hide()) here does not work. This was the reason I just called closed(). hide() does not seem to call it afterwards (same with reject()).
There was a problem hiding this comment.
Yah that was part of the fixes in the other PR.
|
Might as well roll this fix into my pr to fix the dialog behavior |
When the password generator popup has been triggered from browser extension, database lock signal is not handled.
Fixes #9820
Testing strategy
Manually.
Type of change