Not sure how important this bug is as the outcome for users of the API is the same. But there might be some devices out there that acts differently wrt. notifications and other functionality.

Also tested on Android and the notifications are stopped there.

From what I can see, Chrome actually sends the command to stop GATT notifications when asked.
I believe what the peripheral does after that is out of our control. 


btmon logs:


< ACL Data TX: Handle 33 flags 0x00 dlen 9                                                                                                     [hci0] 38.543035
      ATT: Write Request (0x12) len 4
        Handle: 0x002b
          Data: 0000
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                                         [hci0] 38.565359
        Num handles: 1
        Handle: 33
        Count: 1
> ACL Data RX: Handle 33 flags 0x02 dlen 5                                                                                                     [hci0] 38.631834
      ATT: Write Response (0x13) len 0



> ACL Data RX: Handle 33 flags 0x02 dlen 8                                                                                                     [hci0] 45.314659
      ATT: Handle Value Notification (0x1b) len 3
        Handle: 0x002a
          Data: 32

For info, here's a log of my conversation with Bluez folks at #bluez-users:

11:54:55 AM <fbeaufort> Hello! Is that intended that when GATT notifications are stopped in Chromium, notifications keep coming from the peripheral as can be seen in btmon. See https://bugs.chromium.org/p/chromium/issues/detail?id=691983
1:54:06 PM <vudentz[m]> fbeaufort: it should stop the notifications, are you sure there is no other clients subscribed? Do you see a write disabling the notifications?
1:55:23 PM <fbeaufort> I see the write request: https://bugs.chromium.org/p/chromium/issues/detail?id=691983#c2 and the write response
1:55:46 PM <fbeaufort> I think* there are no other clients.
1:57:02 PM <vudentz[m]> fbeaufort: the peripheral seem to be broken if it ignores the disable
1:57:46 PM <vudentz[m]> fbeaufort: check if the handle is really a ccc
1:58:00 PM <fbeaufort> So that would be peripheral's fault right. There's nothing preventing it to simulate an event value changed even if we asked it to stop.
1:58:12 PM <fbeaufort> Right?
1:59:33 PM <vudentz[m]> Right, this area of the spec is not very clear since there is no test covering the stop of the notifications

We've concluded that is be BB8's fault.

Thanks for looking into this!

It seems that the device in question (Sphero BB-8) simply ignores the update of the CCCD and keeps sending notifications.