https://chromium-review.googlesource.com/#/c/352420/ is uploaded for this issue and should be merged back to M52.

Are all devices affected by this? Also I can't see that cl landed in ToT...needs to land there first before M52 branch.

gkihumba, all BLE devices are indeed affected by this when it's the first you connect to them. If you try again to get Services, it will work though.

Your change meets the bar and is auto-approved for M52 (branch: 2743)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/bluez/+/5be279bb1e476f026739871ff46dee0673a867ef

commit 5be279bb1e476f026739871ff46dee0673a867ef
Author: Vinicius Costa Gomes <vcgomes@gmail.com>
Date: Tue May 03 17:56:27 2016

UPSTREAM: gdbus: Fix the ordering of signals

Consider the following example:

/foo
  properties: "A", "B"

/bar
  properties: "C", "D"

If during a given mainloop iteration, property "A" of object '/foo' is
changed, then properties "C" and "D" of '/bar', lastly "B" of '/foo',
the current code will emit the PropertiesChanged signals in following
order: "A", "B", "C", "D".

This may confuse applications that have a dependency on the order of
those signals.

This fixes the ordering, so in the example, the order becomes:
"C", "D", "A", B". This is considered not to be a problem, as
applications may use the flag G_DBUS_PROPERTY_CHANGED_FLAG_FLUSH, so
property changed signals are emitted as soon as possible.

The solution is for each object, to reschedule the signals every time a
signal is emitted.

BUG= chromium:619874 
TEST=emerge bluez and verify with Web Bluetooth script

Change-Id: Ie382c7d0e7d083d19de7d07841b45575de0c8b49
Reviewed-on: https://chromium-review.googlesource.com/352420
Commit-Ready: François Beaufort <fbeaufort@chromium.org>
Commit-Ready: Miao-chen Chou <mcchou@chromium.org>
Tested-by: François Beaufort <fbeaufort@chromium.org>
Tested-by: Miao-chen Chou <mcchou@chromium.org>
Reviewed-by: François Beaufort <fbeaufort@chromium.org>
Reviewed-by: Shyh-In Hwang <josephsih@chromium.org>
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>

[modify] https://crrev.com/5be279bb1e476f026739871ff46dee0673a867ef/gdbus/object.c
[modify] https://crrev.com/5be279bb1e476f026739871ff46dee0673a867ef/gdbus/gdbus.h

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/bluez/+/748c2222ee87585adf3956a526f1414ba6f3cec2

commit 748c2222ee87585adf3956a526f1414ba6f3cec2
Author: Vinicius Costa Gomes <vcgomes@gmail.com>
Date: Tue May 03 17:56:27 2016

UPSTREAM: gdbus: Fix the ordering of signals

Consider the following example:

/foo
  properties: "A", "B"

/bar
  properties: "C", "D"

If during a given mainloop iteration, property "A" of object '/foo' is
changed, then properties "C" and "D" of '/bar', lastly "B" of '/foo',
the current code will emit the PropertiesChanged signals in following
order: "A", "B", "C", "D".

This may confuse applications that have a dependency on the order of
those signals.

This fixes the ordering, so in the example, the order becomes:
"C", "D", "A", B". This is considered not to be a problem, as
applications may use the flag G_DBUS_PROPERTY_CHANGED_FLAG_FLUSH, so
property changed signals are emitted as soon as possible.

The solution is for each object, to reschedule the signals every time a
signal is emitted.

BUG= chromium:619874 
TEST=emerge bluez and verify with Web Bluetooth script

Change-Id: Ie382c7d0e7d083d19de7d07841b45575de0c8b49
Previous-Reviewed-on: https://chromium-review.googlesource.com/352420
(cherry picked from commit 285c1f6625ff29cc75bcbc93b876be164b8d3027)
Reviewed-on: https://chromium-review.googlesource.com/353892
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>
Commit-Queue: Miao-chen Chou <mcchou@chromium.org>
Trybot-Ready: Miao-chen Chou <mcchou@chromium.org>
Tested-by: Miao-chen Chou <mcchou@chromium.org>
Reviewed-by: Shyh-In Hwang <josephsih@chromium.org>

[modify] https://crrev.com/748c2222ee87585adf3956a526f1414ba6f3cec2/gdbus/object.c
[modify] https://crrev.com/748c2222ee87585adf3956a526f1414ba6f3cec2/gdbus/gdbus.h

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Checked this behavior on 53.0.2785.15/ 8530.20.0.

When i choose the BLE device ( Microsoft designer mouse or Microsoft universal keyboard) and try to connect , i see the following output

Requesting any Bluetooth Device...
Connecting to GATT Server...
Getting Device Information Service...
Getting Device Information Characteristics...
Argh! NotSupportedError: GATT operation failed for unknown reason.

Hi! Thanks for testing. Could you contact pbommana for a test device. This doesn't apply to all devices.

I checked on the device from pbommana@ and  was able to see the Device information service info.

Thanks for testing!