**** BEGIN LOGGING AT Mon Nov 02 02:59:59 2015 Nov 02 06:21:24 morning! Nov 02 06:21:34 Herrie|2: https://github.com/webOS-ports/luna-webappmanager/pull/39 (and its associated comment) Nov 02 06:21:40 morphis: ^ Nov 02 06:22:44 We don't have appRuntime in WebEngine, and I didn't even see it on WebKit... so I'm a bit surprise that allowCrossDomanAccess is useless. Nov 02 06:29:49 Tofe: morning Nov 02 06:36:25 Tofe: I'm not 100% sure how this was done in WebKit, but you agree with my assesment that currently it would only allow cross-domain for the 3 prefixes? While it should allow for all. Could be there was some patch elsewhere that wasn't migrated somehow? Nov 02 06:37:34 Tofe: If you have an IPK for me I'm happy to test it Nov 02 08:08:01 Herrie: I agree with your analysis yes Nov 02 08:08:27 But didn't we set the same restrictions for webkit? Nov 02 08:08:33 (I don't have an ipk yet) Nov 02 08:23:47 Tofe: morning Nov 02 08:24:12 I'm not sure, I guess we would've taken care of it somehow. morphis did the webkit stuff so he might know. Nov 02 08:24:20 morphis: ^ Nov 02 08:25:33 I understand that you only want to have limited apps have access to private bus. Just cross domain is pretty much in every single Enyo app that connects to a server somewhere Nov 02 08:28:42 I tested quite some Enyo apps yesterday on TP. All launched it seems. I pulled a log which I'll dig into a bit when I get some time today :) Nov 02 08:29:44 Tofe: Is it me or the splash is only disappearing too early on Enyo 2 apps? I didn't really see it with Enyo 1 somehow? Nov 02 08:38:57 Ah no it also appear on Enyo 1 apps just the time is shorter Nov 02 08:50:06 Herrie|Veer: yes, it's one of the identified problems at the time of the switch to WebEngine Nov 02 08:58:34 Tofe: Did you see my comments about luna-webappmanager crashes and systemui? Nov 02 08:59:11 Seems webappmanager is automatically restarted based on systemd service file, however it doesn't launch systemui after a crash, hence power menu stops working Nov 02 09:22:47 Tofe: See luna-appmanager\Src\base\BootManager.cpp Line 272 Nov 02 09:23:15 It launches com.palm.launcher and com.palm.systemui there. Those would need to be relaunched when luna-webappmgr crashes Nov 02 09:26:54 Ideally we have luna-webappmgr never crash of course, but that's impossible to predict :p Nov 02 09:28:27 Herrie|Veer: yes, I remarked that issue... I guess we should make so that systemd restarts LunaAppManager when he restarts LunaWebAppManager Nov 02 09:29:28 Tofe: Yeah or simply launch the 2 apps again. I'm not sure what's easier/more proper Nov 02 09:29:50 I also posted the logs of hard crash + how to reproduce ;) Nov 02 09:33:16 I'd say restart LunaAppManager makes more sense Nov 02 09:37:37 I'm not sure what else LunaAppManager takes care off.. I.e. what would be the side effect of killing & restarting it. Nov 02 09:37:52 Could be it'll kill running QML apps as well? Nov 02 10:01:46 We'd need to test that I guess to find out Nov 02 10:03:15 mmmh good question. Nov 02 10:03:59 But I still think that systemd should do a part of the job, like sending an event to LunaAppManager or something Nov 02 10:04:58 Not sure that if it's send to luna-qml-launcher the app will no longer care about luna-appmanager. But I can imagine killing luna-appmanager having some kind of negative side effects (i.e. pointers to apps that don't exist anymore etc) Nov 02 10:05:18 I haven't looked too much into the code of it to know how it all works. Nov 02 10:07:10 Neither did I Nov 02 10:07:25 Where's morphis when you need him LOL :P Nov 02 10:07:49 Herrie|Veer: right here :) Nov 02 10:10:21 LOL we found 2 issues :P When 1. luna-webappmgr crashes, systemd will restart it but it won't relaunch com.palm.launcher and com.palm.systemui causing power menu to stop working for example. They're launched at boot by luna-appmanager as soon as luna-weba Nov 02 10:10:21 ppmgr comes online by the looks of it. What would be the best solution in your view to get these relaunched on a crash of luna-webappmgr? Nov 02 10:12:10 2. Seems that we had some cross domain issues with apps in WebEngine. For some reason looked like webkit code would only allow cross domain for com.palm, org.webosports and org.webosinternals which seems odd to me. Since it's quite common for an app to do Nov 02 10:12:10 a cross domain request to get data from a source online. I undestand that you want to limit private luna bus access to above 3 groups Nov 02 10:14:16 Herrie|Veer: for 1: luna-appmanager should look out for luna-webappmgr being restarted and the relaunch the boot-time-started apps Nov 02 10:23:17 morphis: Any role for systemd there or should monitor from luna-appmanager directly? Nov 02 10:24:57 Herrie|Veer: after looking at LunaAppManager's source code, maybe we can have a good solution with just using the state machine in BootManager.cpp Nov 02 10:26:08 morphis: For 2 see Tofe's PR from today for suggested changes Nov 02 10:32:11 We just wonder why it worked ok with webkit2 Nov 02 10:39:24 Tofe: I was looking at 1007 and 977 but I'm a bit confusion of the flow of the request :P When we have Enyo banners for example how are they being dealt with? We have Enyo, luna-next, luneos-components and luna-next-cardshell dealing with notifications so Nov 02 10:39:25 mehow so I got a bit confused on how to fix 977 specifically. Nov 02 11:58:00 Herrie: https://github.com/qtproject/qtwebengine/commits/5.5 Nov 02 12:13:56 Tofe: LOL you're becoming a regular qtwebengine contributor :P Nov 02 12:44:39 Herrie: 1007 now works for me. Had some minor issues with the fields still (body not message, expireTimeout not expiresTimeout) and will do a new commit for those. Also expiring looks a bit strange, too me... not sure what it is supposed to do. Somehow only the icon vanishes, but if you click on the notification area, it will still be there. Nov 02 12:45:56 also swiping notifications away does not really work for me? They are swiped to the very right (I can still see a bit from them) and leave a black space. Looks kind of funny... ;) Nov 02 12:47:26 Garfonso: so if you swipe left on that black area, it reappears ? Nov 02 12:47:49 basically it means the notification hasn't been deleted Nov 02 12:48:34 Tofe: Yeah it gets stuck on the right side of the screen with a few pixels remaining and you cannot delete it Nov 02 12:49:05 You can swipe it back in as well. I think we need to tweak the notification api a bit. Also for 977. Nov 02 12:49:17 What scenario did you use to create it ? Nov 02 12:49:45 btw: if you tap on a notification you get this error message in journal: Nov 02 08:48:10 qemux86 luna-next[365]: WARNING: 08:48:10.957: file:///usr/palm/luna-next/shells/card/qml/Notifications/NotificationArea.qml:135: TypeError: Cannot read property 'launchId' of null Nov 02 12:49:51 and nothing opens.. ;) Nov 02 12:50:12 wow, it's all quite broken, looks like there is no object behind the UI... Nov 02 12:50:45 (this was for a not swiped away notification, but it should expire after 5 seconds) Nov 02 12:51:04 I think expiring is broken, is that possible? What I see is this: Nov 02 12:51:35 We'd also need to cater for miniIcon. For example incoming SMS has a small icon (white) when it's a banner and then when it expands it has a different one, same for email. Nov 02 12:51:47 Icon + title shows up above touch area. Disappears after timer. The black bar above touch area remains. Nov 02 12:52:06 if I tap on the black bar (where the Icon was) I can still see the notification Nov 02 12:52:20 Tofe: Incoming SMS notification with a ls2 call from service to org.webosports.notification/create Nov 02 12:52:32 I can swipe it, but it won't go away and I can't tap it. Nov 02 12:52:52 On latest build you can do this: luna-send -n 1 -a org.webosports.service.messaging luna://com.palm.db/put '{"objects":[{"_kind": "com.palm.message:1","flags":{"read":false, "visible": true},"folder":"inbox","status":"successful","serviceName":"sms","messageText":"Message Text4","localTimestamp":0,"timestamp":0,"from":{"addr":"+461234567890"}}]}' Nov 02 12:53:22 Garfonso: Tap could be because there's no relaunch handler in Messaging app yet Nov 02 12:54:05 no, I don't think so.. it happens even if messaging app is not running and the warning is emitted in NotificationArea.qml Nov 02 12:54:59 Tofe: I'll dig a bit in legacy code for getting specs on both 2.x and 3.x and document it a bit on Wiki. We can then cross check against what we already have and what needs changing/adding Nov 02 12:57:38 Herrie|Veer: do we really want new message notifications to expire after 5 seconds? Or what should expire really do? Just minimize the icon to the notification area? Nov 02 12:58:18 Garfonso: Yes should minimize to notification area, so you can expand it to dashboard Nov 02 12:59:00 But the whole banner/dash api needs some looking at. Tofe fixed a lot of behavior already a little while back. The banner, popup and dashboard now behave like legacy Nov 02 12:59:19 But these are the Enyo ones. They might differ from the one you're using now Nov 02 13:03:44 Seems we might be missing a few minor things in api like smallIcon & dealing with things like sounds. Major functionality is there in general. Also 3.x seems to offer "layered" dashboards for the same app. I.e. if you have 5 new emails there are 5 dashboa Nov 02 13:03:45 rds layered on top of each other for email. Nov 02 13:04:38 yes, I see that in 3.x. :) Nov 02 13:04:46 would make sense for messaging icons. Nov 02 13:05:29 Garfonso: Yes. Tofe fixed all behavioral issues we had already and brought back things like custom height dashes like in LunaCE :) Nov 02 13:05:42 So you can add weather widgets, clocks etc there Nov 02 13:06:26 ah. Great. :) Nov 02 13:07:14 I should have a closer look at expireTimeout; I'm not sure it's managed at all Nov 02 13:07:50 Tofe quite sure it is for the Enyo ones, but the direct ones when creating with LS2 maybe now Nov 02 13:07:58 Because in Testr it works OK Nov 02 13:08:51 Ah wait there's no expireTimeout in Testr I guess Nov 02 15:26:16 finally I'm making some progress with download manager... :) Nov 02 15:31:09 Garfonso: Nice Nov 02 15:31:36 I had a lot of free time when my son was born with mother in law and other people helping out :P Nov 02 15:31:46 Fixed the browser around that time :P Nov 02 15:33:00 JaMa: As per DM can you write down a rough step plan to get a new target included in build? Nov 02 15:33:19 So we can try something with Andolamin's Rpi 2 build? Nov 02 15:33:24 yeah.. will see how that works out. Currently I'm ditching work I'd have to do for my pay job and my wife thinks I'm working on that. ;) Nov 02 15:34:04 Andolamin: where is your layer? Nov 02 15:36:04 JaMa: He has something up at http://github.com/andolamin/meta-rpi-luneos but that needs updating with latest I think Nov 02 15:39:10 And he also has http://github.com/andolamin/webos-ports-setup/tree/alan/raspberrypi Nov 02 15:40:22 I think he said he can use upstream meta-raspberrypi now since his issues are solved with new kernel there Nov 02 15:40:54 So it would just be the meta-rpi-luneos that would be specific for the rpi2 with custom bits Nov 02 15:41:20 Herrie|Veer: it's missing many rpi overrides in bbappends and makes qtbase MACHINE_ARCH (which will significantly slow down our builds) Nov 02 15:42:05 lets see how he updates it, but including it in our builds as-is, will break everything else Nov 02 15:43:02 JaMa: Yeah that's why we'd need some pointers, he's OE and BB n00b like me and you're the guru :) Nov 02 15:45:44 i'm getting this problem with liblunanext-common-qml.so http://lists.qt-project.org/pipermail/interest/2013-April/006892.html Nov 02 15:46:36 removing -fvisibility=hidden -fvisibility-inlines-hidden from CMakeLists.txt solved it Nov 02 15:47:36 Andolamin: http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#building-images-for-more-than-one-machine http://www.yoctoproject.org/docs/1.5/dev-manual/dev-manual.html#best-practices-to-follow-when-creating-layers check sections about using overrides in BSP layers Nov 02 15:55:58 JaMa: What do you mean about qtbase MACHINE_ARCH? Nov 02 15:58:40 until now we were building qtbase as TUNE_PKGARCH Nov 02 15:58:52 your changes are only for rpi, so it makes it MACHINE_ARCH Nov 02 15:58:56 for all MACHINEs Nov 02 15:59:23 which means we'll have to rebuild qtbase and everything depending on qtbase separately for each MACHINE Nov 02 16:01:26 and there isn't simple solution for that read http://lists.openembedded.org/pipermail/openembedded-core/2015-October/111773.html https://lists.yoctoproject.org/pipermail/yocto/2015-October/027083.html https://lists.yoctoproject.org/pipermail/yocto/2015-October/027101.html https://lists.yoctoproject.org/pipermail/yocto/2015-October/027110.html threads Nov 02 16:03:20 Yeah, rebuilding qtbase and all dependencies sucks. I have to do it frequently as I make changes. Nov 02 16:09:13 JaMa: Would getting these patches included in upstream qtbase solve this issue? Nov 02 16:09:41 Seems QT project is happy to accept PR's. Tofe got a couple of them merged recently for qtwebengine Nov 02 16:12:34 Well, for non-critical bugs it will only be for the -dev branch Nov 02 16:16:02 OK so in that case it might take 6+ months before it ends up in something we can use directly. Nov 02 16:16:39 JaMa: Doubt it makes any difference, but I just pushed my current layer to https://github.com/Andolamin/meta-rpi-luneos/tree/develop Nov 02 16:56:24 Herrie|Veer: this kind of stuff is device specific configuration, so nothing which can be just accepted upstream Nov 02 16:56:45 Herrie|Veer: the only efficient solution is to build machine-specific qpa in separate recipe Nov 02 16:56:56 with stable ABI, so that we can exclude it from sstate signatures Nov 02 17:31:11 The Tizen guys apparently got qtbase with wayland-egl to work in their builds. Even released their layers. Unfortunately I haven't been able to get it to work, even with their code, and I know other people who haven't been able to either. Nov 02 17:48:33 JaMa: YOu have any examples of where this is implemented, so we can use it as reference? Nov 02 17:56:18 I removed the qt5 patches. Not 100% sure they were needed for 5.5, I tried once and had issues, but those might have come from elsewhere. Just tried and they're definitely not needed for 5.5.1 - that just leaves the qpa problem to worry about. Nov 02 17:57:26 Hopefully, the wayland-egl issue will be solved soon and it won't be a problem. Nov 02 18:01:35 Herrie: yes, the https://lists.yoctoproject.org/pipermail/yocto/2015-October/027110.html is good example Nov 02 18:01:41 Herrie: but still very inefficient Nov 02 18:23:00 Herrie: https://github.com/webOS-ports/luna-appmanager/pull/10 Nov 02 18:24:43 Tofe: Nice fix! Nov 02 18:25:01 I like state machines :) Nov 02 18:25:23 (yes, I really do!) Nov 02 19:04:24 Tofe: Were you able to replicate some of my crashes? Nov 02 19:04:48 I built with Garfonso's and your fix from this morning Nov 02 19:04:49 with HTML5 notifications, yes, without pb Nov 02 19:04:59 Email: Open app, add account Nov 02 19:05:03 Does it as well for me Nov 02 19:06:18 ok Nov 02 19:12:08 Will test it now to see what's fixed there Nov 02 19:12:14 But I guess not much ;) Nov 02 19:12:30 Maybe Macaw & C+DAV Google Nov 02 19:21:44 Tofe: How is the flow for banner & dashboards in Enyo? Enyo->luna-next->luna-next-cardshell? Nov 02 19:22:06 And the ones for org.webosports.notification in luneos-components->luna-next->luna-next-cardshell? Nov 02 19:23:20 something along these lines, yes Nov 02 19:24:56 Tofe: C+DAV Google is OK now with this morning's fix! Nov 02 19:27:09 :p great Nov 02 19:28:02 Trying Macaw now Nov 02 19:33:14 Macaw gives me "Nov 02 14:29:20 mako LunaWebAppManager[1548]: WARNING: 14:29:20.758: CONSOLE JS: Uncaught TypeError: Cannot set property 'innerHTML' of null" Nov 02 19:33:18 I'll check with webinspector Nov 02 19:36:59 Herrie: what you can do too is stop WebAppManager, and start it with QTWEBENGINE_REMOTE_DEBUGGING=0.0.0.0:6622 LunaWebAppManager --verbose Nov 02 19:37:21 then point a Chrome (or your own browser in desktop :p ) on the ip address of the device Nov 02 19:37:51 OK, how is that different from http://webos-ports.org/wiki/Luna_Next_Remote_WebApplication_Debugging ? Nov 02 19:39:06 ah, no, it's the same :) Just avoids the adb forward if you have wifi, that's all Nov 02 19:42:46 OK Nov 02 19:43:14 Seems something in source/dom/dom.js in Enyo Nov 02 19:43:18 Will look into it more Nov 02 19:50:34 Seems the one in the feed is broken, the one I mailed you runs a lot better Nov 02 19:51:34 Tofe: For the font issue, when I disable the CSS for Preware 2 I get Prelude Nov 02 19:51:56 So it seems that it takes CSS values in App over the generic font preference Nov 02 19:52:21 Maybe you should disable font CSS rendering for apps somehow? Nov 02 19:56:29 Interesting! Nov 02 20:06:08 the apps overload the font ? Nov 02 20:11:37 Yeah Nov 02 20:11:41 It seems so Nov 02 20:11:51 If I disable it in webinspector I get Prelude Nov 02 20:12:42 So amybe when the fonts are loaded should should take the settings.standardFontFamily: "Prelude" and then add the list of the fonts from CSS Nov 02 20:13:26 So you get Prelude + whats in CSS in that order Nov 02 20:13:36 Because it seems it takes CSS + Prelude as order now Nov 02 20:14:09 enyo.css Nov 02 20:14:18 first lines Nov 02 20:19:22 I was thinking, could we hook some javascript inside the PalmSystem.stageReady function? Nov 02 20:19:59 or are there too many cases when it is not called? Nov 02 20:22:50 Tofe: Not sure Nov 02 20:23:14 I think only the webapps don't call it, but I may be wrong Nov 02 20:23:22 I think we should have something in webEngine where it loads the fonts and then prepends it with the settings.standardFontFamily value Nov 02 20:23:54 Tofe: That might work too. Yeah for webApps it should be OK because it might use the browser's font settings anyway Nov 02 20:23:58 And there's no CSS for them Nov 02 20:24:13 It's just for apps where we have a CSS where Prelude is not in there where it's a problem Nov 02 20:24:37 So basically only Enyo 2 apps Nov 02 20:24:43 Enyo 1 apps have Prelude in their CSS Nov 02 20:25:06 we could eventually add a style in the header of the html, and override that value of Enyo 2 Nov 02 20:27:05 Tofe: Yeah, whatever works ;) Nov 02 20:27:15 Might be cleaner then messing with webengine logics Nov 02 20:27:32 But seems it might be a bug somehow as well Nov 02 20:29:00 document.body.style.fontFamily = "Prelude" seems to do the trick Nov 02 20:29:08 apart for the title, I don't know why Nov 02 20:30:22 Ah, onyx Nov 02 20:47:45 Herrie: would look like this: https://github.com/webOS-ports/luna-webappmanager/pull/40 Nov 02 20:47:48 (and it works) Nov 02 20:49:33 ah ? doesn't work for Photos&Videos app? Nov 02 20:50:49 yes, that one doesn't call stageReady. tss. Is it a mistake of the app ? Nov 02 20:51:53 Google tells me it is mandatory for all webOS apps Nov 02 20:52:38 It's supposed to be how the app tells the system to switch from pulsing card to open app Nov 02 20:53:12 On legacy webOS the app would never properly open if you didn't call stageReady Nov 02 20:53:50 ok, so that seems to be a quite alright hook point to fix little details on client side when page is ready Nov 02 20:54:52 Seems reasonable. Only concern I have with adding styles there is that it might affect apps that intentionally try to override the font as well. Nov 02 20:55:46 Sure, but I don't know how to insert my CSS just in-between Enyo/Onyx and the app itself... Nov 02 20:58:26 Yeah, I can't think of a better solution. Nov 02 20:58:51 App developers could still override it with !important Nov 02 20:59:22 Well, the current hook proposal isn't very invasive, it'll be easy to cut it off or modify it if needed Nov 02 20:59:57 Let's try. Nov 02 21:00:28 Yeah - honestly the best solution I can come up with long-term would be to just have the latest stable Enyo 2.x be in /usr/palm/frameworks with Enyo 1.0 (I assume that's still where it's stored) and just patch the CSS there. Nov 02 21:00:53 yes, I agree Nov 02 21:01:07 Speed up app launch by not having to load Enyo off the network, too. Nov 02 21:01:15 But this is as good a short term fix as any. Nov 02 21:01:54 Well, I take back to the network comment. Most ipks would bundle Enyo with the app Nov 02 21:02:03 But it would at least save storage space Nov 02 21:02:30 Tofe: Nice :) Nov 02 21:02:50 Andolamin: Yes because they were told they needed to with Enyo 2 :P Nov 02 21:03:01 Should at least fix it short term Nov 02 21:03:28 For Macaw seems that the browser window it opens for auth doesn't know how to redirect itself back to the app with the token... Nov 02 21:03:29 Herrie: Agreed Nov 02 21:05:01 Also, it seems apparent now why the splash screen disappears too soon. Nov 02 21:05:26 Is it? Nov 02 21:06:40 Yeah. If stageReady isn't being called for Photos app, but the app still loads, then it looks like the splash screen disappears on some DOM event (probably onload) instead of when the app calls stageReady Nov 02 21:07:15 So it would disappear before Enyo has a chance to parse and generate the app. Nov 02 21:07:58 Yeah but we have this on pretty much any Enyo 1/2 app currently Nov 02 21:08:03 So I doubt that's it Nov 02 21:08:11 Even the ones with stageReady Nov 02 21:08:24 Right, it would impact everything, regardless of if stageReady was called Nov 02 21:11:30 onload fires before Enyo does it's thing, then Enyo 1.0 automatically calls stageReady. For Enyo 2.x I believe you have to call stageReady yourself. Nov 02 21:13:35 Tofe: ^ Nov 02 21:13:43 You wrote it, you know best ;) Nov 02 22:04:41 yes, enyo2 has to call stageReady somewhere yourself. If you load webos-lib, then that does it somewhere in the webos.js. Nov 02 22:06:16 from what I know webos-lib calls stageReady quite early... it seems to happen on "load", see here: https://github.com/webOS-ports/webos-lib/blob/master/source/webos.js#L338 Nov 02 22:44:11 Tofe: Your fixes for luna-webappmgr for state machine & Prelude work like a charm! Except for Photos & Videos but we knew that already. It's anyway a rough mock so likely there will be some stageReady in future Nov 02 22:44:22 Garfonso: Issue with account name for C+Dav is sorted :D Nov 02 22:44:41 Was the cross domain stuff not being set properly **** ENDING LOGGING AT Tue Nov 03 02:59:58 2015