[Bluedevil] [Bug 376773] Receiving file (when asking for confirmation) cancels immediately, nothing is received

[David Rosca]

https://bugs.kde.org/show_bug.cgi?id=376773

David Rosca  changed:

   What|Removed |Added

   Version Fixed In||5.8.7
  Latest Commit||https://commits.kde.org/blu
   ||edevil/def41978a6330097ddb1
   ||91328185fa79a1d63df4
 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from David Rosca  ---
Git commit def41978a6330097ddb191328185fa79a1d63df4 by David Rosca.
Committed on 24/02/2017 at 10:44.
Pushed by drosca into branch 'Plasma/5.8'.

ReceiveFileJob: Don't cancel the request right after accepting it

KNotification::closed is emitted also when one of the notification
actions was triggered.
FIXED-IN: 5.8.7

Differential Revision: https://phabricator.kde.org/D4744

M  +3-1src/kded/receivefilejob.cpp
M  +1-0src/kded/receivefilejob.h

https://commits.kde.org/bluedevil/def41978a6330097ddb191328185fa79a1d63df4

-- 
You are receiving this mail because:
You are watching all bug changes.

[Bluedevil] [Bug 376773] Receiving file (when asking for confirmation) cancels immediately, nothing is received

[David Rosca]

https://bugs.kde.org/show_bug.cgi?id=376773

David Rosca  changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
 Ever confirmed|0   |1

--- Comment #2 from David Rosca  ---
Thanks, that's exactly what was wrong. I wonder how it worked before.
Theoretically, the cancel should be rejected by obexd because the transfer was
already accepted, but apparently that's not what is doing.

This should fix it: https://phabricator.kde.org/D4744

-- 
You are receiving this mail because:
You are watching all bug changes.

[Bluedevil] [Bug 376773] Receiving file (when asking for confirmation) cancels immediately, nothing is received

[Jonathan Marten]

https://bugs.kde.org/show_bug.cgi?id=376773

--- Comment #1 from Jonathan Marten  ---
There is a suspicious use of the KNotification signals in
ReceiveFileJob::showNotification().  The signals are connected:

  KNotification::action1Activated   ->  ReceiveFileJob::slotAccept
  KNotification::action2Activated   ->  ReceiveFileJob::slotCancel
  KNotification::closed ->  ReceiveFileJob::slotCancel

The last of these makes sense, to decline the file transfer if the notification
is closed or times out.  However, the API documentation for
KNotification::closed says:

  Emitted when the notification is closed.

  Can be closed either by the user clicking the close button,
  the timeout running out or when an action was triggered.

I haven't looked at the KNotification code for this, but from the description
it would appear that closed() signal is sent, in addition to
action1Activated(), when the "Accept" button is clicked.  This would account
for the calls to slotAccept and then slotCancel in the log.

-- 
You are receiving this mail because:
You are watching all bug changes.