Chrome Version       : 71.0.3572.0
OS Version: 11143.0.0
URLs (if applicable) :
Other browsers tested:  NA this is a chrome App issue.
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari:
    Firefox:
    IE/Edge:

I enabled NewBlue daemon on my chromebook:
Controller 5C:C5:D4:69:D4:B1
        Name: BlueZ 5.44
        Alias: Chromebook_B8E1
        Class: 0x480104
        Powered: yes
        Discoverable: no
        Pairable: yes
        UUID: Headset AG                (00001112-0000-1000-8000-00805f9b34fb)
        UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
        UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)
        UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
        UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
        UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
        UUID: Audio Source              (0000110a-0000-1000-8000-00805f9b34fb)
        UUID: Handsfree Audio Gateway   (0000111f-0000-1000-8000-00805f9b34fb)
        Modalias: bluetooth:v00E0p2420d0400
        Discovering: no


My system details:
CHROME VERSION
71.0.3572.0 dev
CHROMEOS_ARC_STATUS
disabled
CHROMEOS_AUSERVER
https://tools.google.com/service/update2
CHROMEOS_BOARD_APPID
{CCBD0510-9FD5-F4B7-53CA-3EBE6CEA52D3}
CHROMEOS_CANARY_APPID
{90F229CE-83E2-4FAF-8479-E368A34938B1}
CHROMEOS_DEVSERVER
CHROMEOS_FIRMWARE_VERSION
Google_Gnawty.5216.239.156
CHROMEOS_RELEASE_APPID
{CCBD0510-9FD5-F4B7-53CA-3EBE6CEA52D3}
CHROMEOS_RELEASE_BOARD
gnawty-signed-mp-v3keys
CHROMEOS_RELEASE_BRANCH_NUMBER
0
CHROMEOS_RELEASE_BUILDER_PATH
gnawty-release/R71-11143.0.0
CHROMEOS_RELEASE_BUILD_NUMBER
11143
CHROMEOS_RELEASE_BUILD_TYPE
Official Build
CHROMEOS_RELEASE_CHROME_MILESTONE
71
CHROMEOS_RELEASE_DESCRIPTION
11143.0.0 (Official Build) dev-channel gnawty 
CHROMEOS_RELEASE_KEYSET
mp-v3
CHROMEOS_RELEASE_NAME
Chrome OS
CHROMEOS_RELEASE_PATCH_NUMBER
0
CHROMEOS_RELEASE_TRACK
dev-channel
CHROMEOS_RELEASE_VERSION
11143.0.0
CLIENT_ID
a1136edd-f3f0-4913-b957-68269ac17b00
DEVICETYPE
CHROMEBOOK
ENTERPRISE_ENROLLED
Not managed
GOOGLE_RELEASE
11143.0.0
HWID
GNAWTY C2A-E3N-A5M
LOGDATE
Mon Oct 15 14:00:09 IST 2018
Local State: settings
{"audio":{"device_state":{"2 : 1183355409 : 1":{"activate_by_user":false,"active":true},"2 : 1638505488 : 0":{"activate_by_user":false,"active":true},"2 : 1923447123 : 0":{"active":false}},"devices":{"mute":{"2 : 1638505488 : 0":0,"2 : 1923447123 : 0":0},"volume_percent":{"2 : 1183355409 : 1":75.0,"2 : 1638505488 : 0":75.0,"2 : 1923447123 : 0":75.0,"2 : 2315562897 : 1":75.0,"2 : 2356475750 : 1":75.0}}},"display":{"external_display_mirror_info":[],"mixed_mirror_mode_param":{},"port_associations":{},"power_state":"all_on","properties":{"1242109511518210":{"display_zoom_factor":1.0,"rotation":0,"ui-scale":-1000},"3850489720471552":{"display_zoom_factor":1.0,"rotation":0,"ui-scale":-1000}},"rotation_lock":{"lock":false,"orientation":0},"secondary_displays":{"3850489720471552,1242109511518210":{"default_unified":true,"display_placement":[{"display_id":"1242109511518210","offset":0,"parent_display_id":"3850489720471552","position":"right"}],"primary-id":"3850489720471552"}},"touch_associations":{}},"signin_screen_timezone":"Europe/Dublin"}




What steps will reproduce the problem?
1. Configure characteristic to write to device without response:
code:
                txID.properties = ["writeWithoutResponse"];
                console.log("txID:");
                console.log(txID); 

Ouptut of characteristic:
{instanceId: "/org/bluez/hci0/dev_C2_56_89_1A_E7_06/service0009/char000d", properties: Array(1), service: {…}, uuid: "6e400002-b5a3-f393-e0a9-e50e24dcca9e"}
instanceId: "/org/bluez/hci0/dev_C2_56_89_1A_E7_06/service0009/char000d"
properties: ["writeWithoutResponse"]
service: {deviceAddress: "C2:56:89:1A:E7:06", instanceId: "/org/bluez/hci0/dev_C2_56_89_1A_E7_06/service0009", isPrimary: true, uuid: "6e400001-b5a3-f393-e0a9-e50e24dcca9e"}
uuid: "6e400002-b5a3-f393-e0a9-e50e24dcca9e"


2. Write to the device in a realtime loop of 50ms:
code:
         chrome.bluetoothLowEnergy.writeCharacteristicValue(txID.instanceId, bytes, function (){
            if (chrome.runtime.lastError) {
              console.log("BLE Send Error: " + chrome.runtime.lastError.message);
            } 

         });

The write response takes over 100ms to complete. Also rapid writes result in the error status "in progress".


3. Sniff the BLE packets using bt_console->sudo btmon:
The sniffer shows 70ms write responses for every write. Here is the log for a single write event:
< ACL Data TX: Handle 3585 flags 0x00 dlen 27                                                                                                                                                      [hci0] 15.590659
      ATT: Write Request (0x12) len 22
        Handle: 0x000e
          Data: 0000000000000000000000000000000000000000
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                                                                                             [hci0] 15.704396
        Num handles: 1
        Handle: 3585
        Count: 1
> ACL Data RX: Handle 3585 flags 0x02 dlen 5                                                                                                                                                       [hci0] 15.774121
      ATT: Write Response (0x13) len 0


Note the ACL Data RX at the end. I assume this is a write response. In that case it is taking up 70ms of bandwith in my write loop. Is it possible to not acknowledge the write?  



What is the expected result?  
I expect to configure the write API to fire asynchronous writes at the device with out receiving "in progress" errors. If the device cannot process the writes in time, the operation is aborted on the device side. The software doesn't care. It just fires and forgets. 


What happens instead of that?
Two unwanted effects:
1. Lower data transmission wait due to the generation of write responses.
2. "in progress" errors prevent further data transmission resulting in many more dropped packets than would happen in the async case.



Please provide any additional information below. Attach a screenshot if
possible.

This bug appeared to be fixed in 2015:  https://bugs.chromium.org/p/chromium/issues/detail?id=531536
Here's the thread in which it was discovered:  https://groups.google.com/a/chromium.org/forum/#!topic/chromium-apps/D0IIAd0L9sE

However, I do not wish to avail of the callback in the chrome.bluetoothLowEnergy.writeCharacteristicValue() command at all.
Am I mising something i.e. not configuring the characteristic property properly?

UserAgentString: Mozilla/5.0 (X11; CrOS x86_64 11143.0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3572.0 Safari/537.36