Description of problem: Fedora 28 laptop and Lineage OS Moto G3 are paired, and files have been sent. I then run into bug 1596950. I wait a few minutes, and see that phone and Fedora still say there is a connection so I try to send one file and it fails. This could be a DUP of bug 1596950 but I'm distinguishing between an interruption of file sending by closing the GUI panel; versus not having the GUI panel open but with a valid connection failing to send files. Version-Release number of selected component (if applicable): kernel 4.17.3-200.fc28.x86_64 gnome-bluetooth-3.28.0-1.fc28.x86_64 gnome-bluetooth-libs-3.28.0-1.fc28.x86_64 bluejeans-1.35.15-1.x86_64 NetworkManager-bluetooth-1.10.10-1.fc28.x86_64 pulseaudio-module-bluetooth-12.0-1.fc28.x86_64 bluez-libs-5.50-1.fc28.x86_64 bluez-5.50-1.fc28.x86_64 bluez-obexd-5.50-1.fc28.x86_64 How reproducible: Always Steps to Reproduce: 1. Pair laptop and phone. Close GCC-bluetooth panel. 2. Try to send files. 3. Actual results: File fails to send. Expected results: File should send. Additional info: I try to send the file at Jun 30 10:57:01 which shows up in both the hcidump -t output as well as the journalctl output (with bluetoothd -d enabled.)
Created attachment 1455682 [details] hcidump -t
Created attachment 1455683 [details] journal partial Starts shortly before Jun 30 10:57:01 (the time the file send was initiated on the phone).
Created attachment 1455684 [details] journal full This is a complete journalctl -b which contains the whole boot since yesterday, including a lot of bluetooth debugging stuff from various attempts and failures, just in case you want to see literally everything going on.
Created attachment 1455686 [details] hcidump -t "test 2" In this hcidump -t log I start with GCC-bt closed. 2018-06-30 11:33:19.962089 initiate send from phone 2018-06-30 11:33:28.027449 phone says file not sent Jun 30 11:34:20 open gcc bluetooth settings 2018-06-30 11:34:54.112442 initiate send from phone, succeeds This is a 100% reproducible condition so far. Send file fails if GCC-bt is not open, and succeeds when it is open.
Created attachment 1455687 [details] journalctl -f "test 2" In this journalctl partial log, matching with previous hcidump lot, I start with GCC-bt closed. 2018-06-30 11:33:19.962089 initiate send from phone 2018-06-30 11:33:28.027449 phone says file not sent Jun 30 11:34:20 open gcc bluetooth settings 2018-06-30 11:34:54.112442 initiate send from phone, succeeds This is a 100% reproducible condition so far. Send file fails if GCC-bt is not open, and succeeds when it is open.
Receiving files will only work while the panel is opened, that's as designed, implemented and documented: https://help.gnome.org/users/gnome-help/stable/sharing-bluetooth.html.en If the documentation is unclear, please file an issue at: https://gitlab.gnome.org/GNOME/gnome-user-docs
Wow, that is an extremely... interesting... design choice. Instead of popping up a dialog indicating that an incoming file share is being attempted, and giving the choice to accept or refuse it, we just make it silently fail. This used to work, and I actually just thought it was broken in recent times. The user experience I get when I share a file to my laptop — which used to work — is just that my phone says it "failed". Nothing happens on the computer at all. Not even a notification that an attempt was rejected. I'd love to see the usability studies which helped to decide that was the best user experience. Maybe I'm just a really unusual user, in that I like things to either work or tell me why they didn't...