**** BEGIN LOGGING AT Wed Oct 19 02:59:56 2022 Oct 19 06:49:33 Morning! Oct 19 06:51:42 Herrie: yes, we need some luna prefs, I didn't look carefully what is needed exactly, but the cpp you pointed to looks rather simple to read Oct 19 06:52:37 Getting "LuneOS Device" should be quite straightforward, looking at luna-prefs recipe from OSE Oct 19 06:52:53 Tofe: Well we put the values on the file system similar to what OSE does, could be a ls2 call that fails somehow Oct 19 06:53:09 Or some call we need to make in FirstUse to populate stuff Oct 19 06:53:13 Will dig a bit more Oct 19 07:01:10 Yes, it doesn't seem like WAM is setting the all the device info Oct 19 07:05:30 https://github.com/webosose/luna-prefs/blob/master/luna-prefs-service/main.c the com.palm.preferences LS2 service can provide the info, but I wonder why they never used it to fill DeviceInfo Oct 19 07:06:08 maybe it's just low priority for them, and they prefer com.palm.preferences to DeviceInfo Oct 19 07:51:28 I guess I could scan the legacy Doctors to see where else it might be used Oct 19 07:51:54 Might be it's not very needed Oct 19 07:57:25 I can probably add the com.palm.preferences LS2 call in WAM to fill in these things, though doing LS2 in C++ has never been very nice Oct 19 08:00:47 Tofe: Yeah fixing it shouldn't be too hard, but I would expect that there's code in place for it already Oct 19 08:01:06 There was a JS service in legacy webOS for DeviceInfo Oct 19 08:01:20 Just trying to see how it would populate the data for the LS2 call Oct 19 08:02:02 It was in the DeviceProfile service Oct 19 08:02:10 Which we don't have/use for now Oct 19 08:02:25 Which was used for connecting to the Palm servers for various things Oct 19 08:02:30 Such as app catalog etc Oct 19 08:04:44 Tofe: This was the code: https://pastebin.ubuntu.com/p/VwrcbnQ83Y/ Oct 19 08:05:06 Call to palm://com.palm.preferences/systemProperties/getSomeSysPropertiesObj Oct 19 08:06:15 well the API is still there Oct 19 08:07:04 We can also migrate the C+DAV js code, if it's the only place we use DeviceInfo this way Oct 19 08:11:17 Tofe: Yeah it seems some edge cases where this deviceinfo is used probably Oct 19 08:11:29 Adding a check for webOS.Open is easy of course Oct 19 08:14:50 lunaprop -m gives the right value Oct 19 08:18:53 Hmmz: https://pastebin.ubuntu.com/p/84Tgh8kswN/ Oct 19 08:22:26 luna-send -n 1 luna://com.palm.preferences/systemProperties/getSomeSysProperties '[{"key":"com.palm.properties.deviceName"}]' Oct 19 08:22:26 [ { "com.palm.properties.deviceName": "LuneOS Device" } ] Oct 19 08:22:28 That works Oct 19 08:23:00 But the call is deprecated according to https://www.webosose.org/docs/reference/ls2-api/com-webos-service-preferences/ Oct 19 08:33:15 Let me just check for "webos.Open" as device name for now ;) Oct 19 08:36:00 well, all the system properties API are deprecated, so what are we supposed to use :p Oct 19 08:37:00 https://www.webosose.org/docs/reference/ls2-api/com-webos-service-systemservice/#osinfo-query that one maybe? Oct 19 08:39:43 Maybe yes Oct 19 08:42:04 Well that fixed the issues partially, but now we have another... Oct 19 08:42:06 Uncaught TypeError: Cannot read property 'open' of undefined Oct 19 08:42:14 In "navigator.InAppBrowser.open(url);" Oct 19 08:44:59 Seems that was an extension we had Oct 19 08:45:15 Curious if WAM offers something similar Oct 19 08:45:36 ah yes, we had that Oct 19 08:46:43 Let me try something else Oct 19 08:46:47 I don't think WAM provides it Oct 19 08:52:18 Seems not indeed Oct 19 08:52:30 There are some references to InAppBrowser in Chromium 91 code Oct 19 08:54:32 https://github.com/webosose/chromium91/blob/master/src/chrome/browser/apps/intent_helper/intent_picker_internal.cc#L112 this is probably unrelated to our InAppBrowser extension Oct 19 08:55:16 I'd say it's part of the logic triggered when clicking on a link or something like that Oct 19 08:58:56 mmh restoring the extension in WAM looks like quite some work; we don't have QML there, and the browser integration is different Oct 19 09:00:42 can't we just replace it with simply new card? it doesn't look like it's widely used: https://github.com/search?q=org%3AwebOS-ports+InAppBrowser&type=code Oct 19 09:09:36 Tofe: Well I guess we could, but then maybe the return value would not work somehow, not sure Oct 19 09:09:45 There must have been a reason why we did this crossapp stuff Oct 19 09:11:41 To me it looks like it's just a way to have a "modal" webview for asking credentials and stuff Oct 19 09:13:48 Tofe: Yeah it is Oct 19 09:13:52 But then it passes things back Oct 19 09:14:06 I guess it might work in a new card as well Oct 19 09:14:10 I guess we only know when we try Oct 19 09:24:53 Seems this code was there before InAppBrowser: https://github.com/webOS-ports/org.webosports.service.contacts.carddav/commit/dd58c59447f12c501690413817816c78165fc482 Oct 19 09:27:21 maybe there were some issues with window.open, not sure Oct 19 09:27:48 Hard to say, I guess they prefered the "integrated" approach ;) Oct 19 09:29:19 Well it opens Google when I restore that code Oct 19 09:29:29 But getting another error, but could be due to Google changing stuff recently Oct 19 09:29:34 Let me try older image Oct 19 09:29:39 See if it still works there Oct 19 09:30:09 I.e. Might be related to https://github.com/webOS-ports/luneos-testing/issues/5 Oct 19 09:31:55 Nope, seems related to this Oct 19 09:31:59 On old image it still works Oct 19 09:33:08 Ah wait, there I get 400 invalid request too Oct 19 09:33:54 Just a bit later in the process Oct 19 09:42:54 OK seems a recent "blocker" by Google from October 3rd: https://developers.google.com/identity/protocols/oauth2/resources/oob-migration Oct 19 09:55:12 So that will need some migration... Built in Chromium code might help there actually Oct 19 09:55:24 https://developers.google.com/identity/protocols/oauth2/resources/oob-migration#chrome-app-client Oct 19 09:57:59 Ah yes, good finding Oct 19 09:58:47 Or this one: https://github.com/googleapis/google-api-nodejs-client Oct 19 09:59:02 That's for WebApps, uses NodeJS, might be more what we're after actually Oct 19 10:00:18 Specifically: https://github.com/googleapis/google-api-nodejs-client/blob/main/samples/oauth2.js Oct 19 10:01:30 you sure ? I thought we were looking for an app solution, not a "server-side" nodejs service Oct 19 10:11:15 Well it's mainly used for getting the token from what I understood Oct 19 10:11:24 To auth the access from our services Oct 19 10:11:42 Will need to look more into the code Oct 19 11:49:26 We're using Garfonso's key still, asked him for the info for required scopes etc, so we can take it over from webos.ports@gmail.com account instead Oct 19 12:04:52 good idea Oct 19 12:07:07 And then can take it from there Oct 19 14:37:49 Seems codepoet is working on some OAuth stuff for Exchange on legacy webOS, so we might be able to combine some efforts there, checking with him **** ENDING LOGGING AT Thu Oct 20 02:59:56 2022