**** BEGIN LOGGING AT Mon Mar 07 02:59:57 2022 Mar 07 07:17:26 Morning! Mar 07 07:41:57 Moning! Mar 07 07:44:22 Herrie: I tried investigating this getResource, yesterday, but it seems to me that the c++ webos plugin for webOSSystem isn't completely fonctional Mar 07 07:46:15 JS calls C++ in the frame's process, but then it sends an IPC call that should end up in the main process, and I don't see that happening. It's included in the build, but I never seem to go there in gdb Mar 07 07:47:25 I also tried to modify the C++ callback to always return a fixed string, but I never see the string returned. So the code actually isn't called, it's weird Mar 07 08:10:51 Tofe: Hmmz weird indeed Mar 07 08:11:04 This is for which problem? The JS frameworks? Mar 07 08:11:23 yes, in Enyo 1.0 apps Mar 07 08:11:41 Enyo 2.0 apps are embedding enyo locally, so the issue isn't that visible Mar 07 08:12:14 but MojoLoader is doing a "getResource" to parse the manifest.json of each framework, which fails Mar 07 08:13:16 Is quite easy to test, now that we have remote debugging with chromium; just try to do "webOSSystem.getResource("/etc/fstab") " and that'll return an empty string Mar 07 08:16:26 Tofe: Ah OK, I was debugging a bit in Mojoloader from my side but nothing obvious here Mar 07 08:16:30 there Mar 07 08:21:07 Well I don't have that many details either; there's nothing in the logs, so it's not easy to see what fails. I hope "getReource" is still actively supported by WebOS OSE ? Mar 07 08:21:16 getResource* Mar 07 08:32:23 Tofe: I recall we added some calls for sync stuff in our custom webengine Mar 07 08:32:28 That wasn't there Mar 07 08:32:48 Not sure if that might be related? Mar 07 08:34:02 HerrieTP: it's related yes, but LG implemented it differently, much more integrated within chromium code Mar 07 08:34:15 Tofe: Ah OK Mar 07 08:34:24 I meant this commit: https://github.com/webOS-ports/qtwebengine/commit/4c3fe5604603a27849843db7160a7f7e90d0012c Mar 07 08:35:23 Yes, exactly; we only hacked the Qt layer, which doesn't even exist in webruntime Mar 07 08:36:58 to be more precise: we are called here: https://github.com/webosose/chromium91/blob/master/src/neva/injection/renderer/webossystem/webossystem_injection.cc#L594 Mar 07 08:37:39 but then , we never reach that layer: https://github.com/webosose/chromium91/blob/master/src/neva/pal_service/webos/platform_system_delegate_webos.cc#L122 Mar 07 08:41:27 You'll notice there is absolutely no restriction whatsoever on the file path we want to read ;) Mar 07 08:42:26 Personnally, when this will work, i'm tempted to add a restriction for the path not beginning with /usr/palm Mar 07 08:42:37 but we're not there yet Mar 07 08:51:45 Tofe: Well I guess LGE would be open for some patches Mar 07 08:51:59 I did notice there are some paths whitelisted in a conf file Mar 07 08:52:07 I remember I added something there before Mar 07 08:52:17 Either Chromium or WAM need to check Mar 07 08:52:43 Well, I'll first try to tackle the main issue :) Mar 07 08:52:52 It could be checks are performed against that Mar 07 08:53:02 Or you could reuse that file for allowed paths Mar 07 09:58:25 Tofe: I meant this conf file for WAM: https://github.com/webOS-ports/wam/blob/3e06ca69b893bafdbe2b6148d57be9a615326333/files/launch/security_policy.conf Mar 07 10:01:44 Without the last entry our apps wouldn't load at all Mar 07 10:02:01 ah, ok Mar 07 10:02:13 I guess we'd need to add the cryptofs path here too Mar 07 10:02:17 For the user installed apps Mar 07 10:05:05 probably yes Mar 07 10:05:37 but I think that's only related to the checks WAM does on the appinfo Mar 07 10:10:13 Tofe: WEll without adding the "/usr/palm/applications" I would get a network error Mar 07 10:10:19 When trying to load the apps Mar 07 12:14:15 Herrie: Tofe: will force-push rebased version of honister branch (to remove the merge confict commits, so that I can cherry-pick the same commits to master branch) Mar 07 12:16:24 + 703bdbbb0...3f212d964 honister -> honister (forced update) Mar 07 12:17:57 ok, so we'll have to be careful on our next update of meta-webos-ports I guess Mar 07 12:19:10 yes, better rebase now when older honister and current is almost the same Mar 07 12:19:40 the only difference from my rebase is one Copyright line Mar 07 12:19:59 and then I've added 2 more commits from master (which aren't needed for honister, but better to keep the delta smaller) Mar 07 15:43:57 Tofe: I'm working on 5.15.3 update in meta-qt5, will need to update your patches in qtwayland-webos and luna-surfacemanager a bit to match the version Mar 07 15:44:00 just FYI Mar 07 15:49:28 ok ! Mar 07 15:58:52 built ok now with kirkstone (and jansa/master branch of meta-qt5 and meta-webos-ports) NOTE: recipe luneos-dev-image-1.0-r0: task do_rootfs: Started Mar 07 18:37:32 Herrie: https://github.com/webOS-ports/meta-webos-ports/pull/500 this should ok for merge, now Mar 07 18:37:36 +be Mar 07 18:37:53 Tofe: Didn't I merge that yesterday already? Mar 07 18:37:56 Or this is rebased somehow? Mar 07 18:38:28 I don't think it was merged no, I didn't reopen it at least Mar 07 18:39:30 With this, we should have the best so far, and I'll now continue on the getResource issue thing Mar 07 18:49:30 OK great Mar 07 18:49:38 I'll merge it in a bit Mar 07 18:58:50 JaMa: if I read the chromium code correctly, it looks like the implementation of PalmSystem and such are only completely provided when "wam_demo" is active... do you know what "wam_demo" is ? Mar 07 18:59:26 it looks like an executable that is able to embed one appId Mar 07 19:00:01 but it could be also I didn't read correctly the source code, as it's so vast Mar 07 19:24:42 Now trying a bold move, changing chromium's webos code to instantiate the webossystem C++ objects Mar 07 19:25:11 Not even sure what I'm doing tbh :) Mar 07 19:30:26 nope, doesn't work Mar 07 19:45:03 Ah, found it ! I wasn't actually looking in the right place Mar 07 19:46:03 So the issue is that in here: https://github.com/webOS-ports/wam/blob/master/src/platform/webengine/PalmSystemBlink.cpp#L33 there is no implementation for getResource Mar 07 19:46:51 I'll draft a basic implementation and we'll see Mar 07 19:57:33 ah, great, it worked :) Mar 07 19:57:48 doesn't really improve our situation visibly, unfortunately Mar 07 19:57:54 though the loading error are gone Mar 07 21:04:36 it looks like Enyo isn't fully initialized, somehow **** ENDING LOGGING AT Tue Mar 08 02:59:57 2022