**** BEGIN LOGGING AT Sat Sep 12 02:59:58 2015 Sep 12 03:05:02 … and added a new bug (sound isn’t played for Banner notifications): http://issues.webos-ports.org/issues/977 Sep 12 03:05:23 I’m not complaining, I’m excited to see us moving forward! Sep 12 06:58:58 DougReeder_: I'll test it later today Sep 12 06:59:18 thanks! Sep 12 06:59:28 On the bug: I saw that too, should be easy to fix (we simply didn't implement it), should be a matter of adding a luna call to play the sound Sep 12 06:59:43 Tofe: I can just do that in the Banner QML ? Or you have something else in mind? Sep 12 07:02:35 DougReeder_: Should be similar to https://github.com/webOS-ports/luna-next-cardshell/blob/master/qml/Notifications/VolumeControlAlert.qml#L96 Sep 12 07:12:03 * DougReeder_ nods Sep 12 07:16:26 Herrie: the html5test.com bug is far from being obvious; it's offscreen window that create a real temporary window for QtWebKit to paint inside it Sep 12 07:22:19 Herrie: seems fine to do it in the Banner QML Sep 12 07:22:59 You can trigger it when a line is added in MergedModel, for instance Sep 12 07:26:04 also you can add some led light Sep 12 07:28:04 and vibration Sep 12 07:39:05 mmmh it wouldn't be mergedModel only, it will also be bannerPopupModel... Maybe it's best to it in the code at the beginning of the qml NotificationArea file just when these objects are added to the models Sep 12 07:39:13 +do Sep 12 07:44:16 I didn't even know HTML5 notifications existed :) Sep 12 07:53:15 TOfe: Yeah it's a weird one... It's not really an issue I think but well ;) Sep 12 07:53:22 For html5test.com that is Sep 12 07:56:40 Herrie: no no, it's an issue, it is a wrong way of dealing with not yet mapped windows that are never meant to be visible Sep 12 07:58:07 I don't know yet how to handle this correctly.... We don't want to delay the appearance of the loading card animation, but we don't want to show a card animation when the window will never be visible... Sep 12 07:59:28 Ah ok Sep 12 07:59:51 I'm sure you've had more difficult challenges ;) Sep 12 08:13:23 :) we'll see Sep 12 11:08:06 Tofe: Added fullscreen mode in browser Sep 12 11:08:09 Seems to work OK Sep 12 11:08:18 Just pushed it to ports branch instead of my own fork :P Sep 12 11:08:21 So no PR Sep 12 11:08:28 Works OK on Youtube for me :) Sep 12 11:11:19 Removed the UA hack for Youtube because it would serve rstp streams in most of cases Sep 12 11:31:10 Ok good Sep 12 11:32:39 We might want to trigger exit of full screen when the gesture area is touched Sep 12 11:33:33 yup Sep 12 11:34:40 In case teh player doesn't provide a way to exit full screen mode Sep 12 12:12:18 Herrie: Could you try that ? It is based on latest fido and may fix the issue with temporary windows popping up: https://dl.dropboxusercontent.com/u/4679068/luna-next/luna-next_0.2.0-26%2Bgit1%2B88a81dea8b-r0.1_armv7a-vfp-neon.ipk Sep 12 12:12:41 Corresponds to this: https://github.com/webOS-ports/luna-next/pull/106 Sep 12 12:12:52 It works on my N4 at least Sep 12 12:20:34 Herrie: oops, seems my PR introduced a bug Sep 12 12:25:08 ok, PR fixed Sep 12 12:25:48 please take https://dl.dropboxusercontent.com/u/4679068/luna-next/luna-next_0.2.0-26%2Bgit1%2B88a81dea8b-r0.2_armv7a-vfp-neon.ipk instead Sep 12 12:26:14 This won't fix Macaw, though. I don't know yet what the problem with that one. Sep 12 12:51:55 Tofe: DOes it fix FeedSpider? Sep 12 12:53:03 dunno Sep 12 12:53:23 I doubt it, it really only fixes the spawning windows issue Sep 12 12:53:31 Tofe: I'm on latest stable need to reflash ;) Sep 12 12:53:47 Will do in a bit Sep 12 12:53:52 But I really think it's a totally different issue Sep 12 12:58:32 Herrie: maybe we could add something like https://danlimerick.wordpress.com/2014/01/18/how-to-catch-javascript-errors-with-window-onerror-even-on-chrome-and-firefox/ (window.onerror) to debug a bit what is the JS DOM error we get with Macaw? Sep 12 12:59:34 Now let's flash 4.4.2 ! :D Sep 12 13:02:41 woops, it should be 4.4.3, first mistake... The debug begins well... Sep 12 13:38:05 Don't we have 4.4.4 as well? Sep 12 13:38:31 Well, morphis said he tested the issue with 4.4.3, I don't want to debug something useless Sep 12 13:39:23 I think he did 4.4.2 but not 100% sure Sep 12 13:39:46 This says 4.4.3: http://git.shr-project.org/git/?p=meta-smartphone.git;a=commitdiff;h=35ed44de2b82aff7c54e2e8011a846a3288d6da3;hp=3f1866c4bb5410f97742998cde0cd7f937ce2c93 Sep 12 13:41:05 I rebased it on top of fido, it seems to work Sep 12 13:41:45 not rebased, cherry-picked Sep 12 13:42:12 OK Sep 12 13:42:22 THat's good in general ;) I'm flashing fido now Sep 12 13:53:30 Tofe: Luna-next fix seems decent enough :) Sep 12 13:53:35 html5test.com behaves OK now Sep 12 13:55:23 good Sep 12 13:58:21 Macaw seems to open 2 windows while I think only 1 is required. This could be due to Enyo 1 registering taps twice somehow Sep 12 13:58:42 I have seen this twice registering of taps in other Enyo 1 apps like Email, Accounts and Tweaks too Sep 12 13:59:18 ah, this is a weird behavior... Sep 12 14:04:04 Yeah so I can imagine Macaw is awaiting response from the 1st window while actually the 2nd is returning it Sep 12 14:04:10 Hence maybe the funny DOM 12 error? Sep 12 14:05:23 maybe Sep 12 14:06:36 Anyway this double registering of tap only happens in Enyo 1, Enyo 2 is OK Sep 12 14:09:25 Tofe: You know you need to flash 4.4.3 to your N4 before you install LuneOS based on 4.4.3? Sep 12 14:09:41 Just a friendly reminder :P I forgot that in the past and got stuck on silly stuff :P Sep 12 14:10:37 Herrie: yep, that's what I did Sep 12 14:19:07 ok, at least the bug with leaking fds is quite obvious in the logs: "msmfb_handle_buf_sync_ioctl: get_unused_fd_flags failed" Sep 12 14:21:19 I think my twrp recovery version is bugged... Which version do you use? Sep 12 14:24:44 Let me check in a bit Sep 12 14:24:50 Will test testr now Sep 12 14:27:06 DougReeder_: Did you test it yourself? Sep 12 14:27:13 I'm trying cwm, in case it works better Sep 12 14:27:34 yes, looks much cleaner Sep 12 14:27:53 (and it works with my antedeluvian adb) Sep 12 14:27:54 I get "requesting Notification permission" which could be fine because I don't think we implemented anything for that yet Sep 12 14:28:12 I have CWM Sep 12 14:28:14 I don't think our Webkit has it Sep 12 14:28:56 CWM 6.0.4.7 is what I have on my N4 Sep 12 14:30:04 I have 6.0.4.6, but it worked well Sep 12 14:30:09 I'll trash twrp Sep 12 14:30:21 I think I had 6.0.3.8 before which was fine too Sep 12 14:35:51 Tofe: Seems there's a notificationsEnabled experimental ;) Sep 12 14:36:03 oooh Sep 12 14:40:16 It will still ask for the permissions then. I guess I need to add the onPermissionRequested as well Sep 12 14:40:42 I guess so Sep 12 14:42:39 Yeah Sep 12 14:42:47 Will add that later to luneos-components I guess? Sep 12 14:42:54 We don't want it browser only right? Sep 12 14:42:59 Might need it for geolocation too Sep 12 14:43:05 ANywya off to hairdresser now :P Sep 12 14:43:09 Need a cut badly :P Sep 12 15:23:19 ahah, I did that this morning :) Sep 12 15:23:32 Yes, luneos-components is the right place I think Sep 12 15:56:48 Herrie, I tested the new code in Testr extensively. Is that what you're asking? Sep 12 15:58:26 DougReeder_: It doesn't give me the banner just a permissions request ;) Sep 12 16:35:44 Herrie: from what I read in the code, it's normal, isn't it ? It has to get the permission before sending the notification Sep 12 17:34:59 Herrie, when I try the HTML5 notifications under LuneOS, the process stalls when requesting permission. Sep 12 17:37:46 Given that all installed apps can send banner messages, I think Notification.permission should return GRANTED for all installed apps, and requsting permission should immediatly return. Sep 12 17:38:37 Eventually, we'l need a dialog for this in the browser, but that's distinct. Sep 12 17:47:49 Tofe: Yeah but I mean he cannot have fully tested it on LuneOS when there's no permissions set ;) In a desktop browser maybe yes Sep 12 17:49:01 ah ok yes Sep 12 17:53:40 It looks like using fido to test the issue with hwcomposer wasn't such a marvellous idea Sep 12 17:53:54 Quite a lot of things are broken Sep 12 17:55:56 mmh "LunaAppManager[1551]: Failed to load libGLESv2" Sep 12 17:58:49 Tofe: Hmmz don't think I saw that on mine Sep 12 17:58:51 Let me check Sep 12 17:59:08 no no, don't bother, it may well be my build that is a bit inconsistent Sep 12 17:59:37 Well I can just pull a journalctl no big deal ;) Sep 12 17:59:47 I think it might be your combo of fido + 443 Sep 12 17:59:57 that's quite sure :) Sep 12 18:01:24 I don't have that one in my journalctl Sep 12 18:02:46 I think you would have seen a lot of symptoms: apps crashing, everything unstable, etc Sep 12 18:06:04 Yeah Sep 12 18:06:10 Lte me run the openGL tests Sep 12 18:06:45 Well they do seem to crash after a few seconds of me moving my finger Sep 12 18:10:47 Seems better after reboot Sep 12 18:10:53 Maybe I was low on memory Sep 12 18:21:32 Tofe: For Feedspider 2 it seems it's looking for cordova.js which is not included ;) Sep 12 18:22:52 Testing now with it removed Sep 12 18:23:15 If that works will notify Aressel, he either forgot to include it while packaging or it shouldn't be there altogether Sep 12 18:25:19 ah ok, that could explain Sep 12 18:35:47 The HTML5 Notification test runs correctly in current Firefox & Safari. Under Chrome the notifications are persistent, which does not match the spec. Sep 12 18:37:32 The spec defines persistent notifications in connection with Web Workers. We don't those yet in our version of webkit, right? Sep 12 18:48:23 DougReeder_: Probably not Sep 12 18:48:32 But Chrome's implementation might be wrong Sep 12 18:49:01 I read something about inconsistencies and support problems for HTML5 notificiations across various platforms Sep 12 18:50:29 In general, there's need for both transient notifications (banners in webOS) and persistent notifications (dashboards in webOS). Sep 12 18:52:16 tying persistent notifications to web workers, rather than browser windows is reasonable. I think the Chrome team is reluctant, because they implemente it firsst. Sep 12 18:52:40 So I expect Chrome to fall in line eventually. Sep 12 18:53:44 they don't have the Not Invented Here attitude that Apple, Microsoft & sometimes Mozilla have. Sep 12 18:55:46 So, yeah, browser behavior is not all consistent yet, but I expect that will be fixed over time, in favor of the standard. Sep 12 18:57:34 http://caniuse.com/ is the place to check for what browsers support. Sep 12 19:50:48 The HTML5 notifications are now permitted but don't show it seems :s Sep 12 19:50:56 I guess we need to build osmething for that :P Sep 12 19:51:15 I just get the permission granted message but not the notification itself ;) Sep 12 20:01:34 * DougReeder smiles “That doesnt surprise me” Sep 12 20:17:05 Seems QTWebKit doesn't support it out of the box :S Sep 12 20:17:47 Seems we'll might need this or something similar: https://github.com/QupZilla/qtwebkit-plugins Sep 12 20:18:58 But maybe Tofe has another suggestion ;) Sep 12 20:19:05 He's quite a magician in QML ;) Sep 12 20:29:12 Herrie: I prefer logic to magic :p Sep 12 20:33:04 Herrie: the plugin you found is pretty interesting ! Sep 12 20:33:56 We could fork it, simplify it to strip hunspell out of it, and use it almost out of the box, as we already manage DBus notifications Sep 12 20:34:39 We still need to implement that timeout more correctly, but it's not a big thing Sep 12 20:37:20 Hop, forked Sep 12 20:39:39 I just have no idea how to plugin this plugin :P Sep 12 20:48:19 I guess we put it somewhere near the other qt plugins Sep 12 20:49:33 " target.path = $$[QT_INSTALL_PLUGINS]/webkit " Sep 12 20:50:12 It sounds like the Notifications plugin is separate from the spelling plugin. Sep 12 20:56:13 Almost, yes. It will be easy to get rid of it. Sep 12 20:59:45 Hop, simplified ! github.com/Tofee/qtwebkit-plugins/ Sep 12 22:10:43 Tofe: nizovn did the other plugins ;) Sep 12 22:10:46 For browser Sep 12 22:14:14 Not really sure how to integrate this :S https://github.com/webOS-ports/org.webosports.app.browser/tree/master/plugin **** ENDING LOGGING AT Sun Sep 13 02:59:58 2015