On a 2.1 KK Flame, most of the bluetooth tests fail with the same stack trace: JavascriptException: NS_ERROR_FAILURE: stacktrace: execute_script @bluetooth_test.py, line 110 inline javascript, line 176 src: " app = null;"

This occurs because the returned value of getDefaultAdapter() contains a 'uuids' field which can't be serialized by Marionette.

(In reply to Jonathan Griffin (:jgriffin) from comment #1) > This occurs because the returned value of getDefaultAdapter() contains a > 'uuids' field which can't be serialized by Marionette. The problem is actually that this field cannot be accessed at all; attempting to access 'uuids' (even just calling typeof() on it) generates a NS_ERROR_FAILURE exception. Although we could work around this with a little work, this seems like a bug in the Flame KK build. Al, how do you want to handle it? (We had a similar problem with an OEM a few months ago, is this a bug in our bluetooth stack?)

This potentially seems related to bug 1059136.

I'll take care of this one on finding resource to fix it if possible.

Ben, do you think it's possible to provide solution from Mozilla side? Or, we'll need partners' input?

I'll take a look. :)

Clear my ni? per comment 6.

[Blocking Requested - why for this release]: Mozilla QA team is working on the release of MCTS for v2.1. Please refer to https://bugzilla.mozilla.org/show_bug.cgi?id=970615#c44 The MCTS bluetooth tests would fail on v2.1 when it attempts to access 'BluetoothAdapter.uuids'. 'BluetoothAdapter.uuids' was exposed on Bug 1059136, however, it didn't uplifted to v2.1 yet. Request for 2.1? since this bug blocks the release of MCTS v2.1 (Bug 970615)

Decided to put it to 2.1.

Comment on attachment 8553497 [details] [diff] [review] (for 2.1) [bluedroid] Expose adapter uuids field. (v0) Move the review process to Bug 1125033 since the patch is belong to Bluetooth.

Hi Jonathan, This bug was caused by Bug 1125033. Since the Bug 1125033 has been fixed, would you mind if I close this bug ?

I'll do a test locally and close the bug if it's fixed. Thanks for your kindly help, Jamin.

Still encounter failure: JavascriptException: JavascriptException: InternalError: too much recursion stacktrace: execute_script @bluetooth_test.py, line 110 inline javascript, line 176 src: " app = null;" I am going to look into the issue.

The failure happens in webapi_tests/app_management.js Line 176

The failure is trapped in gecko/dom/apps/AppsService.js Line 68~70 getAppLocalIdByStoreId: function getAppLocalIdByStoreId(aStoreId) { debug("getAppLocalIdByStoreId( " + aStoreId + " )"); return DOMApplicationRegistry.getAppLocalIdByStoreId(aStoreId); },

(In reply to Al Tsai [:atsai] from comment #16) > The failure is trapped in gecko/dom/apps/AppsService.js Line 68~70 > > getAppLocalIdByStoreId: function getAppLocalIdByStoreId(aStoreId) { > debug("getAppLocalIdByStoreId( " + aStoreId + " )"); > return DOMApplicationRegistry.getAppLocalIdByStoreId(aStoreId); > }, E/GeckoConsole( 2386): [JavaScript Error: "too much recursion" {file: "jar:file:///system/b2g/omni.ja!/components/AppsService.js" line: 69}]

return attributes as an object instead of returning whole javascript object https://developer.mozilla.org/en-US/docs/Web/API/BluetoothAdapter

Comment on attachment 8571220 [details] pr234 comment on github

merged

This does not fix the problem, at least on my Flame. It just changes the error. The root of the problem is the bluetooth adapter's 'uuids' field. To fix the issue, you'd have to omit line 120 of https://github.com/mozilla-b2g/fxos-certsuite/pull/234/files Do the tests now pass for you on a Flame?

from my side, uuids problem has been fixed and I can correct grab the uuids field. However, there's a new issue happened that the bt_adapter cannot be returned as a object. On my device, the code ''' marionette.execute_script("return window.wrappedJSObject.bt_adapter;") ''' will simply return an empty object. I was told that some of the JSObject return by gecko cannot be stringified. That's why I change the return value with grab the attributes we need only. What's the build you are using now? I'd like to flash to your build and re-test it again. Thank you for letting me know.

I'd like to know the build you are using. We tested with the latest v2.1 build w/ v18D-1 as base image and it works for us.

Hi Al, I didn't realize something in the build had changed to improve this situation. I flashed the latest 2.1 build and confirm the problem does not repeat.

Great. Thanks a lot.