00:00:00 scribe- 00:00:24 RRSAgent, make minutes public 00:00:24 I'm logging. I don't understand 'make minutes public', marcosc. Try /msg RRSAgent help 00:02:34 02:23:54 Linux_Kerio has joined #webapps 04:40:57 Guest85 has joined #webapps 06:28:57 AramZS has joined #webapps 08:30:02 Github has joined #webapps 08:34:05 bluepenquin has joined #webapps 08:34:05 EllaGe has joined #webapps 08:34:06 PenelopeMcLachlan has joined #webapps 08:34:06 JakeArchibald has joined #webapps 08:34:07 GlennHartmann has joined #webapps 08:34:07 MikeWasserman has joined #webapps 08:34:08 rego has joined #webapps 08:34:09 PeterConn has joined #webapps 08:34:10 RayanKanso has joined #webapps 16:39:34 RRSAgent has joined #webapps 16:39:34 logging to https://www.w3.org/2022/09/13-webapps-irc 16:40:40 scribe+ 16:40:48 Currently discussing candidate recommendation issues: https://github.com/w3c/manifest/milestone/1 16:41:01 topic: Candidate recommendation https://github.com/w3c/manifest/milestone/1 16:41:41 looking at how to specify scope recommendations, same - origin web apps, etc: https://github.com/w3c/manifest/pull/1034 16:41:52 issue: https://github.com/w3c/manifest/issues/539 16:41:52 Sorry, but no Tracker is associated with this channel. 16:42:16 reillyg: Safari seems to maybe partition storage etc so having different apps on same origin are actually isolated 16:42:21 etienne has joined #webapps 16:43:00 marcosc: Yes, I think this happens, with own permissions, but does integrate with OS. But Chrome is different, and we would probably need to document what is same and what is different. 16:44:05 ... there are also tests still to write around scopes 16:44:29 Next issue: https://github.com/w3c/manifest/issues/673 16:45:03 tomayac: People can easily lock themselves out because some implementations don't include the back button in 'standalone' 16:45:14 ... the old Edge had a back button in Standalone 16:45:42 ... Chrome has added the media query feature so the developer can know if a back button is present, so the developer can know whether they need to display one or not 16:46:16 dmurph: The feature is in navcontrols: https://drafts.csswg.org/mediaqueries-5/#nav-controls 16:46:56 ... proposed in https://github.com/w3c/csswg-drafts/issues/4187 16:47:29 tomayac: Safari doesn't run into this problem because on desktop there isn't install yet, it's only on mobile, which always is full screen 16:48:02 ... webkit has a proprietary window.standone property 16:48:25 marcosc: This tell you if you have been added to the homescreen or not 16:48:44 tomayac: navigator.standalone 16:50:53 dmurph: is this solved by the media queries? display-mode and navigation-buttons? 16:51:03 tomayac: we have only speced the media query for back button 16:51:28 tomayac: Regarding if the developer needs to know if the app is installed, they need to know if they should 'pitch' install to the user 16:52:07 tomayac: There is also a getRelatedApplications API, so the developer can know, say, if the Android/native app is installed already 16:52:19 ... so they know they don't need to pitch installation 16:52:53 marcosc: There is a meta tag for WebKit, it knows that the app is installed on iOS, so it opens directly. 16:55:08 ... what is the stance on whether we need to bring back this thing or not 16:55:42 dmurph: So we probably have the 'navigation controls' solved with display-mode and navigation controls media query, do we need to solve the new use case here of 'do we want to prompt installation'? 16:59:10 dmurph: Penny how do you feel about adding this? something like adding 'is installed'? 16:59:24 PenelopeMcLachlan: It seems like the media query solves this? 17:00:02 q+ 17:00:13 q- 17:00:45 tomayac: The media query should show all information from the @media display-mode feature, and navigator.standalone doesn't add anything 17:02:09 PenelopeMcLachlan: in a time machine, navigator.installed is the property, and navigator.install triggers UI. With navigator.standalone, it seems useful to support for interop, but developers should be thinking about the things changing w/ window decorations, so we might want to encourage the display-mode media query 17:02:36 tomayac: mdn makes it pretty clear to not use navigator.standalone 17:05:00 ri_ has joined #webapps 17:05:14 Guest85 has joined #webapps 17:05:17 dmurph: Do we want to have a way for the developer to know whether the web app is installed from the web page? 17:06:21 PenelopeMcLachlan: There are more use cases than just promotion, like times when a standalone experience is better they could prompt the user to launch into the installed app. Devs can already spam installation, so it doesn't seem like it would hurt to have this feature. 17:06:52 christianliebel: So based on discussion, and because Edge no longer has a back button here, we can close this. 17:07:22 Could we also take some time today to look at multi-origin scope - https://github.com/w3c/manifest/issues/964. After lunch is fine. 17:08:18 Next issue: https://github.com/w3c/manifest/issues/755 17:08:37 scribe- 17:08:47 LuHuang: Can you add it to the agenda wiki doc? 17:08:49 gsnedders has joined #webapps 17:09:14 shttps://github.com/w3c/webappswg/wiki/TPAC-2022 17:09:17 https://github.com/w3c/webappswg/wiki/TPAC-2022 17:09:19 scribe+ 17:12:12 marcosc: This seems very browser-specific. We haven't spec'd what happens when navigation goes out of scope, as the manifest is no longer applied 17:12:48 marcosc: Main concern is that we don't over-codify things here based on whatever browser-specific behaviors there are. Because different browsers would have different behavior for out-of-scope navigations 17:13:51 marcosc: This pull request seems reasonable: https://github.com/w3c/manifest/pull/880, looking at it now 17:15:41 marcosc: That seems fine, it just needs to be rebased and we should check over what Ben Francis said 17:16:47 action: perhaps ask mgiuca@ to rebase https://github.com/w3c/manifest/pull/880? 17:16:47 Sorry, but no Tracker is associated with this channel. 17:17:27 Next issue: https://github.com/w3c/manifest/issues/784 17:22:16 xiaoqian has joined #webapps 17:24:22 Conclusion: we will leave this open - it looks like this has kind of been resolved with us codifying using the document url in the spec algorithms, and we may just add a note to say that installation can happen from urls that link a manifest that are out-of-scope of the manifest scope (but still same origin) 17:25:22 Next issue: https://github.com/w3c/manifest/issues/910 17:25:48 marcosc: This is possible now because we resolved the whole 'whether you can use a manifest w/o a document' discussion 17:27:22 dmurph: So how to we resolve this then? Where do we connect this? 17:28:08 marcosc: So this would happen in the same process as, say, css loading a background image. So we would want to check other specs like CSS to see how they specify the document here in this loading path 17:28:54 marcosc: I'm not seeing a lot of new stuff w.r.t. the other issues that are coming in. So we will be busy for a little while. 17:30:38 dmurph: So this means that we may fetch all images every time we see the link, so having a manifest version would be really helpful to NOT refetch all the time 17:30:43 marcosc: Yes 17:30:50 scribe- 17:31:43 RRSAgent, make minutes 17:31:43 I have made the request to generate https://www.w3.org/2022/09/13-webapps-minutes.html marcosc_ 17:32:07 RRSAgent, make log public 17:37:16 AramZS has joined #webapps 17:46:25 AramZS has joined #webapps 17:49:04 RRSAgent, make minutes 17:49:04 I have made the request to generate https://www.w3.org/2022/09/13-webapps-minutes.html xiaoqian 17:52:17 meeting: TPAC 2022 WebApps WG meeting 17:52:26 chair: marcosc, tink 17:54:02 s/// 17:54:07 RRSAgent, make minutes 17:54:07 I have made the request to generate https://www.w3.org/2022/09/13-webapps-minutes.html xiaoqian 18:05:31 tantek has joined #webapps 18:05:39 present+ 18:08:11 scribe+ 18:08:16 marcosc has joined #webapps 18:08:35 topic: App Identity Updating w.r.t. images (manifest version, token, per-image token, etc). Doc: https://docs.google.com/document/d/11qoRuZRU2W7eKCimhcu2TmJS4jvJ65-Nz8_n9Fidrlg/edit 18:08:42 TOPIC: Updates 18:12:16 dmurph: We get false positives for image updating detection, as the bytes can change due to on-demand compression strategies from CDNs etc 18:12:47 dmurph (IRC): we could have a version token in the manifest 18:13:05 dmurph (IRC): we will show a 'reinstall' like dialog, showing the old and new 18:13:41 JakeA (IRC): This is to stop apps changing to look like your bank? 18:13:47 dmurph (IRC): yes 18:14:06 dmurph (IRC): whenever they want their images to change they update their token 18:14:17 dmurph (IRC): another way is manifest URL change 18:14:34 risako has joined #webapps 18:14:46 diekus has joined #webapps 18:17:50 jsbell has joined #webapps 18:22:03 q+ 18:29:28 Lots of discussion about: 1 we could just require url to change, 2 we could use fancy image diffing algorithms ... 18:29:41 3 having a version token 18:30:28 PenelopeMcLachlan: The version tag does seem to have usefulness in other areas, like file handler updates, other things that means it's a useful tool for developers to specifically signify an app should be fully updated 18:30:51 PenelopeMcLachlan: Is it worth prompting 5 million old users for a 5 pixel change in my logo? 18:31:31 PenelopeMcLachlan: It might have potential with the MSFT changelog proposal, which would allow developer to disclose what has actually changed in the app. It could be a moment to disclose to the user that the app has shipped a bunch of new functionality 18:31:43 ... one of the things users like about the update process is that the new version has new stuff for them 18:32:14 ... on the web, we talk about how amazing it is to have apps update. But users are unaware that this is happening, and so it's a significant moment for developers to tell users something significant has changed about the application 18:32:26 This is the explainer mentioned by Penelope: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/VersionHistory/explainer.md 18:32:40 +1 PenelopeMcLachlan re: "on the web, we talk about how amazing it is to have apps update." as a differentiating advantage vs "native/installed" apps 18:32:44 Penelope McLachlan: apologies for not following the queue 18:33:30 JakeArchibald: What about the issue that images might not update for everyone if you update the version and old images might be downloaded? 18:33:48 marcosc: That issue might be out-of-scope - maybe get a better CDN? 18:34:09 reillyg: You can roll out the new icon first, test it, and then update the manifest version 18:35:08 JakeArchibald: Part of this is about how cache headers work, max age and next request. It's by design that if you are changing content under a url, and it has caching, the only reliable way to update that resource is by changing the URL 18:35:54 marcosc: If you know this is a critical resource then, you are probably setting that max age appropriately. Having that escape hatch is useful. Having the version token is the best of both worlds. 18:36:57 dmurph: App updates are also not as foreign a concept as serviceworker update - users & developers are familiar with app updates 18:37:49 tomayac: The mini apps have a same thing here with a version field, semantic versioning & ordering. 18:37:59 marcosc: We don't want to do that 18:39:28 tomayac: What about apps that are never navigated or reloaded? 18:39:54 JakeArchibald: The SW spec mandates that we check on navigation, and we hard limit max age of script to 24 hours. Says that browsers can run update check whenever you want 18:40:09 ... maybe at 3am you could do a check in the background? 18:41:20 dmurph: Might be weird because you need the document linking the manifest to parse & load the manifest 18:41:38 tomayac: What about an app that the user hasn't launched in a long time? Do we want to keep in out of date? 18:41:49 marcosc: Yes, for privacy reasons, we don't want to update name & icon here 18:42:04 ... if a short name changes, is that enough of a signal w/o a version token change as well? 18:42:20 ... or should we treat the version token change as the only signal for a true update 18:42:46 ... We could do both 18:43:15 tantek: +1 PenelopeMcLachlan re: "on the web, we talk about how amazing it is to have apps update." as a differentiating advantage vs "native/installed" apps 18:44:12 christianliebel: It would be easy to not notice that the update doesn't happen for users, as developers often use fresh state 18:44:59 marcosc: Fair. It does no real harm to change url and add fragment identifier at end of images 18:46:19 tomayac: What about manifests that might have this field already? 18:47:25 JakeArchibald: Most compelling argument is the updates that you explicitly don't want to update 5 million users. updating an apostrophe to another thing. 18:47:49 reillyg: Also prevents you from updating image technologies 18:49:14 Evan Stade: Does this mean we want all silent fields to also not update until version token changes? 18:50:10 PenelopeMclachlan: I've had this argument with myself - it is nice to say 'things only update with version change' but also that might not be obvious / we definitely could still have updates happen on non-sensitive members 18:50:46 marcosc: A more complicated model is that the version token is null, by default, and then by specifying the token we respect the update model based on the token being there, instead of being the change happen in the manifest 18:51:33 marcosc: You can remove yourself by removing version token later too 18:51:38 PenelopeMcLachlan: I like that 18:51:52 dmurph: To clarify - without version token, images are only considered to be changed if url is changed 18:52:12 ... but if you have version_token, then nothing changes unless you change that 18:52:27 JakeArchibald: Seems fine to me 18:53:15 JakeArchibald: This sounds like etag 18:53:31 ... this is a caching header 18:55:25 dmurph: What about the edge between non-version token and version token? 18:56:40 JakeArchibald: If the version token changes but nothing else has changed, then don't show update 18:57:49 reillyg: If you add a version tag when you didn't have one before, then you get that for free. If you also have an icon update, then you would want to change the icon url AND add the version token in the same change. 18:58:29 Evan Stade: There may be a technical reason why they don't want to change the URL. So maybe we also detect image bytes? Or maybe we ALWAYS show an update dialog when you add the version token? 18:58:44 marcosc: It might be good to force the update then 18:59:13 JakeArchibald: I don't like that. You have an app and don't have a version token. If you then add one of those, it seems bad for users to then get a version update. 18:59:16 present+ 18:59:31 Evan Stade: Hoping that the user wouldn't see that change if there isn't a visible change. 19:02:30 dmurph: We will always false-positive trigger icon bitmap changes for certain sites 19:03:13 q+ 19:03:20 q- 19:03:41 reillyg: There is a clear list of security sensitive fields and not security sensitive fields, and we can have those non-security sensitive fields update silently 19:03:51 ... even with the token. 19:04:11 tomayac: What about removing the version_token tag? 19:05:35 jsbell: I wonder if the remove and addition of the field - if that can be addressed by saying there is a default - empty string. 19:05:44 estade has joined #webapps 19:06:14 reillyg: In the absence of a token, we are doing the url-checking. by providing a default value that is not null, then that behavior differentiation breaks. 19:06:24 q- 19:06:25 q+ 19:07:04 https://www.w3.org/TR/appmanifest/#dfn-security-sensitive-members 19:07:33 dmurph: We could have sentinel that users can specify as initial version if they don't want to trigger update 19:08:16 JakeArchibald: Case where you update images, then realize that you didn't change the version, and then you update the token. But - you don't want the users who got the new image to get the update prompt. 19:09:54 JakeArchibald: If we require change to the icon url, then users getting the fresh version would NOT get the update 19:10:04 reillyg: Starts to get annoying to dev, but seems to be necessary 19:10:34 ... If you are making some non-important change to the icon, you can change the data and not name, and get away with it 19:11:05 xiaoqian has joined #webapps 19:11:51 action: dmurph follow up with alancutter & Penny about this discussion, come up with scenario table, conclusion proposal. 19:11:51 Sorry, but no Tracker is associated with this channel. 19:12:11 marcosc: Would be great to re-use beforeinstallprompt 19:13:47 marcosc: The only case where you want to notify the developer is if you are going to disturb the user to update the app. the developer can say "i'm not ready" 19:19:21 PennyMcLachlan: Interested in talking about making navigator.install (declarative install) and deprecating beforeinstallprompt. Idea - no doc or anything 19:19:40 marcosc: For other apis, like permissions, we have added a webdriver. We could do it there. 19:20:37 PennyMcLachlan: the reason beforeinstallprompt is difficult to test is that things would be broken because there are many things like serviceworker registration, fetch handler, etc, it would be too flaky and beforeinstallprompt would be flaky 19:21:01 ... maybe this should be something that is more in the user's control and not developer's control 19:21:32 ... We could be getting a signal from the developer that the user would like to install, but it's just a signal. We could try to be smart here (button vs on load of page) 19:22:00 marcosc: This is why we removed install signals from the spec, they can be so nebulous and install is under user's control. 19:22:22 ... Where it gets tricky is having the web site have control over the install prompt. "Install our app". 19:22:49 ... `beforeinstallprompt` addresses that problem in a fairly elegant way. So delicate balance there. 19:23:15 ... I would probably push back on `navigator.install`, even if behind button 19:24:07 PenelopeMcLachlan: Trying to think of similar examples - sites that are gating access to content on users participating on things that are user-hostile. Notifications come to mind. 19:24:34 q- 19:24:43 ... I could imagine something very similar happening in the install world. But a similar set of mitigations that we are taking in mitigations could be done here. 19:25:12 marcosc: I get this, these smarts are great, but really challenging. Pre-supposes a bunch of smarts. 19:25:27 ... Safari's perspective - the user is in control, we don't really care about installability signals. 19:25:52 PenelopeMcLachlan: I would love developers to be able to participate in install actions similar to other app ecosystems. 19:26:19 ... the users currently still need to seek in the browser UI itself and display help text. 19:26:54 marcosc: We also don't want sites to try to force users to click on things like "click on add to homescreen" 19:27:24 PenelopeMcLachlan: Next step in this discussion would be to start a doc about how the UI might work, and what ways can we discourage developers from being user-hostile 19:28:06 marcosc: I'm not a huge fan of digging into a menu in Safari to do this. The question for Chrome folks w/ install prompt - has it been an issue, is it really that bad? What are challenges with beforeinstallprompt? 19:28:53 PenelopeMcLachlan: First, developers who want to be able to offer users to install their PWA, and not create an Android app. They want to offer an install button "Hey, it looks like you bought a new pair of sneakers, do you want to install our app?". The beforeinstallprompt model is brittle for doing that. 19:29:09 marcosc: We gave you beforeinstallprompt, and there is enough signal that we can now offer you this API 19:30:06 PenelopeMcLachlan: Flip side, let's say that any arbitrary news site that is not meeting install criteria - why shouldn't I be able to "app-ify" that website irrespective of whether the developer is hitting technical criteria. App UX is a capability of the browser. 19:31:04 marcosc: Do the banner, and this is signaling "you have access to this API". Before the user sent it away, but there is enough signal there? They dismissed it, but they didn't hate it. There's something here that could work. 19:31:14 PenelopeMcLachlan: Complicated set of tradeoffs here, appreciate the discussion. 19:32:02 RRSAgent, make minutes 19:32:02 I have made the request to generate https://www.w3.org/2022/09/13-webapps-minutes.html xiaoqian 19:49:01 hartmanng has joined #webapps 20:20:31 AramZS has joined #webapps 20:35:13 bradley has joined #webapps 20:44:02 Guest85 has joined #webapps 20:45:54 jsbell has joined #webapps 20:46:45 scribe+ 20:46:57 topic: How do we make the working group more effective? 20:47:00 present+ 20:47:06 present+ 20:48:59 marcosc: This group has a long legacy. Joined in 2007. There were weekly meetings, and then there were less meetings. Now there are new people & faces, which is fantastic. Would like to see some change, refreshing leadership at some point, what are the goals? 20:49:18 ... We can set ourselves a mission of some sort. How to achieve that? Culturally as well. Are we OK with how things are going? 20:49:47 ... The w3c are OK with us moving along, as we have many really important specs. File spec, IDB, etc. We want to get as many as we can to CR as possible. 20:50:35 ... We should care about IPR commitments. 20:50:46 .. We used to have 20 specs, now there are less. Trying to get them down & be more manageable. 20:51:25 ... Do we kill the working group? Do something new? The name 'WebApps' is good, so that is good. 20:52:12 scheib: Good to take a bigger picture view sometimes. What does the group care about? What are things that we might be missing? Hey, brainstorming-wise, how are we doing, what are we missing, are there any ideas about what we should be thinking about? How can we improve? 20:52:21 ... we should always be in a growth mindset. 20:52:38 hakan has joined #webapps 20:53:06 ... I would suggest people think about it and chime in, if they have thoughts about whether we are working towards the charter. Is our rate of progress reasonable? Is our work satisfying those goals? 20:54:03 jsbell: Agree with the concerns. When introducing team members, there are some working groups that are really productive, and then the WebApps working group is a grab-bag of things. Sometimes there isn't much, sometimes there is. Really happy that there is such engagement on manifest stuff this year. 20:54:16 ... in 2019 there was a ton of interest in IndexedDB, that was great 20:54:43 ... Curious if folks are aware of other grab-bag working groups that are working effectively, or no, there is too much stuff in the charter and it's not serving the things we are trying to work on. 20:54:59 tomayac: What does "web app" mean? Progressive web app? Run in browser tab? Standalone? 20:55:04 q+ 20:55:23 ... is this something that we are not comfortable on the web? Or do we want to force a store download? etc 20:56:05 marcosc: The charter is fairly clear. We set the scope, but the scope is really set by the specs we are working on. But as tomayac said, we don't make the distinction if something is installed or not. 20:56:26 ... we often have a 'feeling' that something should be in our spec. Contacts, IndexedDB. Serviceworker ended up being it's own working group. 20:57:32 reillyg: Just pulled up the charter, the scope is interesting. Interested in what Marcos said - do we need this? Or do we split up or turn into something else? 20:57:42 ... html, for example, could encompass every single spec. 20:57:57 ... One end case is to put all into html spec? Or is that not how we do things? 20:58:18 .. If not, we are going to need some group charter with a scope of maintaining specifications in this area. 20:58:48 marcosc: HTML gives us hooks into things that we use, like url parsing. Gamepad, attaching to navigator for instance. 20:59:12 Charter is here: https://www.w3.org/2019/05/webapps-charter.html 21:00:09 Oli: UI Events have been around forever. IndexedDB is very core. Some of kind of the 'edge' of the web. 21:00:30 marcosc: I like the idea that input events could be the own thing. Database & storage could be their own thing. 21:00:51 Oli: And maybe some things would have priority? 21:01:16 marcosc: Interesting with priority, maybe, for example, we put more resources between UI Events because it's so important 21:02:25 estade has joined #webapps 21:03:33 Gary: Since we're not able to take the spec in it's current state, it needs to be modernized. into HTML spec? Some core parts are in HTML spec. Dispatching. But in terms of event order, the task of fixing that first requires we identify all of those problems. Have a core algorithmic spec for this, and looking at pointer events. Long term pain, is that when pointer events etc creates things, it can't be as algorithmic 21:03:46 tantek has joined #webapps 21:03:47 marcosc: What should we then change? Should we change our working mode? Should we have more meetings? 21:04:36 Gary: Working mode for something like UI Events would be different than other specs here. Until I get some traction on it, it is hard to attract people to help. It's not exciting. 21:06:41 jsbell: The needs are the different specs are very different. Some (locks & idb) need better integration with other specs. Is it hindering that they are outside those spec 21:06:50 ... spec's orgs? Maybe not. 21:07:32 q+ 21:07:41 q- 21:08:10 dmurph: It would be great to know what could happen. What are some imaginary options? 21:10:18 garykac has joined #webapps 21:10:44 tomayac: There are a lot of things that are urgent-ish. 6 or so people, but not everyone in the room. Why not do mini-summits and meetings about these things instead of yearly at tpac? 21:11:12 ... but it doesn't have to be regular. 21:11:20 q+ 21:11:28 marcosc: Who can commit more time for some of these? 21:13:47 marcosc: Happy to have feedback, now or in the future. Chair rotation, editor rotations, meetings, etc 21:14:02 Gary: Are there restrictions with meetings and announcing attendance? 21:14:30 marcosc: There should be a public record if we do meet, but there are no restriction or anything about who can meet and collaborate. People who have time. 21:15:02 present+ 21:16:10 marcosc: Meeting physically is kind of nice, overcome that social barrier. With device api working group, there are great virtual meetings. bash through a bunch of stuff 21:22:52 I have made the request to generate https://www.w3.org/2022/09/13-webapps-minutes.html xiaoqian 21:29:00 topic: Manifest Override https://github.com/w3c/manifest/issues/1045 21:29:05 q- 21:29:50 scribe+ 21:31:06 dmurph: discussion of how MediaQueries works 21:31:14 In this proposal 21:31:22 main thing is dealing with darkmode/lightmode 21:31:42 when app is launched, mode is extracted from media query. 21:31:57 (1) what do we want to support in general 21:32:05 (2) how to we get this to run on startup - on launch 21:32:21 eg: on launch logic happens that checks background color 21:32:32 what other impl options? 21:34:02 dcrousso has joined #webapps 21:35:19 on launch, we need to know what css media features are supported. 21:35:35 media queries are primarily about the device 21:35:50 there are a few about the browser, but most are about the device 21:36:19 eg: multiple displays, one supports a color space, while the other one doesn't 21:37:27 ???: we could recycle for format of media queries, but not support everything. 21:37:31 why not? 21:37:46 supporting everything is hard. partially because the app hasn't yet launched. 21:38:03 s/???/tomayac/ 21:38:27 q+ 21:38:54 browser needs to figure out the media query. race condition between launching and getting result of media query. 21:39:55 we could store the manifest info in a plist for the native 21:40:17 what if screen geometry changes - a new monitor is added? 21:40:22 theh stored plist would not be updated. 21:40:39 ???: plist is same as manifest (at launch) 21:40:47 louise: need an entire parser for this 21:41:36 reilly: concern: we provide a filtering lang - look for device with these properties 21:41:53 then we need to translate that filtering into whatever the native platform needs 21:42:12 we can make it work by asking for all devices and doing out own filtering 21:42:32 but huge space of expressible queries that are not translatable into native formats. 21:42:39 what is the fallback in that case? 21:42:44 say it's not supported? 21:42:58 not a satisfying experience. 21:43:09 eg: something expressable on iOS but not on Android 21:43:21 we need to be careful about what we sa we support 21:43:29 ???: don't we have this already today? 21:43:49 same situation: one is in the OS but the other is in the browser. 21:44:07 people need to test these things to make sure they work in the scenarios they care about. 21:44:29 eg: iOS can't necessarily support requests for dark mode variants 21:44:40 but other platforms could possibly support that 21:44:56 reilly: we'll need a set of examples so we can explore this 21:45:15 what we have here is a browser mediated interface to the native platform 21:45:23 and that can cause problems. 21:45:33 so a set of key examples would be great 21:45:57 marcosc: we acknowledge that it's a big "ask" 21:46:12 but we already have this language (Media Queries) 21:46:31 but it does add a huge burden on the implementors 21:46:43 we could choose a simpler route, but that's not as powerful 21:47:31 ??? = dcrou 21:48:08 marcos: reviewing some of the samples 21:48:14 we have an expression "16/9" 21:48:39 need to a parser for aspect ratio for a display 21:48:56 dmurph: what are the examples for where people need this aspect ratio check 21:49:25 devin: eg: size of icon 21:49:49 we also need to bear in mind future benefits of being general 21:49:58 dmurph: but we don't want to over engineer 21:50:35 dcrou: nothing about the manifest spec is limited to native apps - also used by browsers 21:51:11 it's basically a bucket of metadata instead of a bunch of fields. 21:51:29 dmurph: what is hover 21:51:47 dcrou: it's the primary pointing device 21:51:55 anyhover = any pointing device 21:52:08 also pointer granularity: coarse - fine 21:52:27 dmurph: can dev require that app can only be installed on device with certain conditions 21:52:43 dcrou: possibly. so we shouldn't restrict it 21:52:50 these are already adjustable from JS 21:53:15 dmurph: hard part: is this feasible to implement at startup - on splash screen on launch 21:53:29 marcos: it's a HUGE ask 21:53:59 dcrou: we've thought about pulling the Media query parser into something sharable. 21:54:23 dmurph: better context: engineering resource contraints 21:54:39 so the more specific use cases we have, the easier it is to rationalize the work 21:55:31 dcrou: one benefit for Webkit, we didn't have to write a new parser (since we already have a parser for Media Queries) 21:56:24 reilly: which keys from the manifest? 21:56:51 dcrou: mostly display related 21:58:11 dmurph: for things that are nested 21:58:23 eg: want to change icons because it's french 21:58:35 do we just substitute the entire icon field in there? 21:59:01 marcosc: have to look it up. 21:59:30 icons override: put the query, then put the things you want after that 22:00:03 louise: shortcuts 22:00:29 do we allow certain parts (like just the icon) of the shortcuts, or do you need to override the whole thing. 22:00:40 marcosc: need to have the whole thing - it's simpler. 22:01:23 overall: do people think this is too much? or is it worth trying? 22:01:41 louise: rather not commit at this time to hoisting out the parser. 22:01:52 would like to see more details in the spec 22:02:19 marcosc: to the room: DOES ANYONE OBJECT? 22:02:37 Webkit is willing to try it to see how it works. 22:03:05 louise: unlikely to put a lot of work into this until we can see a good use case. and we don't have one at the moment. 22:04:18 schieb: we only need a few things at the moment, but the value of Media Queries is making it future proof. 22:04:35 dcrou: also developers are already familiar with MQs so that's convenient. 22:04:56 schieb: could be subset a subset of MQ? 22:05:26 dcrou: we can do that with this. each UA can support a subset to support. 22:05:46 advantage: as new things are added to MQ, they are automatically supported by this system. 22:06:29 marcosc: We'll spec this a bit more and and work in impl, with the expectation that people should feel free to object later. 22:07:07 elle: What other things change quickly? 22:07:40 prefers reduce motion, contrast, colors, ... 22:08:05 s/elle/ella/ 22:08:31 tomayac: what about SVG? 22:08:46 dcrou: doesn't work well (works on launch but doesn't update) 22:09:52 Guest85 has joined #webapps 22:10:05 tomayac: can we reuse code from SVG 22:10:16 dcrou: not sure. but doesn't like current SVG behavior 22:11:28 ericwilligers has joined #webapps 22:11:47 marcosc: calling time on this discussion since we're part 3:00pm 22:12:17 dmurph: to clarify: adding language to the spec to handle the language case 22:13:05 marcosc has joined #webapps 22:13:31 RRSAgent, draft minutes 22:13:31 I have made the request to generate https://www.w3.org/2022/09/13-webapps-minutes.html marcosc 22:37:23 present+ 22:38:41 AramZS has joined #webapps 22:42:33 marcosc has joined #webapps 22:42:46 TOPIC: Push API 22:43:27 dgrogan has joined #webapps 22:44:11 scribe+ 22:44:37 marcosc: We've identified that it is quite expensive to create a service worker in order to show a notification. 22:44:58 ... We would like to explore situations where we could skip the service worker and show the notification directly from the push message. 22:45:05 ... Saves resources. 22:45:55 ... Is this something we would like to explore? 22:46:07 ... Is this a Javascript side of things or protocol side of things? (W3C or IETF) 22:46:34 gsnedders: This is currently the common case for native apps on iOS. 22:46:44 ... Web apps have a greater performance and power cost for notifications. 22:46:54 q+ 22:47:06 q- garykac 22:47:07 q- 22:47:55 martinthomson has joined #webapps 22:47:57 We missed the "multi-origin scope" topic in the last session. Could we add it to this session? I would like to know if others find the problem useful to solve and if the scope_extensions proposal is a suitable solution. 22:48:18 can someone link me to context for this? 22:49:02 q? 22:49:12 reillyg: so, two things, this makes a lot of sense to me. Have we looked at SW workers on the web and what do they do? Or is it that they do almost nothing and what is the common case of what push messages on the web do. It would be as if we are providing this shorthand for this behavior. 22:50:36 brady: We've discussed that this be registered at Push registration time. 22:51:15 q+ 22:51:20 ... For example, in Intelligent Tracking Prevention we have a carve-out for sites that have a Service Worker. We would like to remove this carve-out without blocking push. 22:51:23 q- 22:52:09 martinthomson: The service worker doesn't launch until there is a request so what is the concern from a tracking protection perspective? 22:52:29 q- martinthomson 22:53:28 brady: If a site opted into a fast-track push handling we could remove the service worker. 22:54:08 ... The existence of service workers is a tracking vector, which is why ITP wants to unregister them. 22:56:12 martinthomson: With the pre-registered message handling you still need to maintain state (like cookies) necessary to handle the click on the notification. I don't see how the Service Worker is anything special. 22:56:26 ... I understand the other benefits of this proposal. 22:56:50 tomayac: also confused about the ITP 7 day active usage cap. 22:57:13 tomayac: I'm confused about the ITP 7 day active usage cap. 22:57:40 gsnedders: After 7 days all storage, including the service worker is removed. 22:58:39 marcosc: If you register for the fast path you can't do things like fetch in response to a push. 22:58:55 martinthomson: In order to use the fast path you need some state to decrypt the message. 22:59:37 reillyg: you would still retain the tiny piece that is the subscription itself, which is not what the site can use as a tracking vector ? 23:00:05 ...depending on the application, this might not be useful. if it were something that needed login, then you might receive the message, but can't act on it 23:00:13 ...this seems more useful for the spammy uses of notifications 23:01:11 scribe+ martinthomson 23:01:43 gsnedders: To my knowledge the state for receiving the message it already stored outside the browser. 23:01:55 martinthomson: I think that's assuming things about push notifications infrastructure. 23:03:11 martinthomson: In Chrome we need state in the browser to understand the content of the message. 23:03:38 s/Chrome/Firefox 23:04:26 martinthomson: This is an appealing proposal from a performance. I'm just pushing back on the ITP aspect. 23:04:46 gsnedders: The larger motivation on our side is also performance. 23:06:21 PeterConn: This would also allow the browser to load a page instantly when the notification is clicked. 23:06:59 martinthomson: This is totally workable as long as we figure out the structure of the fields. 23:07:24 marcosc: Knowing the protocol side, Martin, does this make sense to do at subscription time or in the protocol. 23:07:30 tantek has joined #webapps 23:08:22 martinthomson: Where would the instructions for how to handle the message be stored? 23:08:27 draft explainer for what I was talking about: https://github.com/PEConn/notification-launchurl-explainer/blob/main/explainer.md 23:09:03 martinthomson: Most appealing option from my perspective is to send the payload of the notification in the message with a different payload type. 23:10:03 marcosc: The Notification launchURL proposal seems like a piece of the solution. 23:11:14 diekus has joined #webapps 23:11:19 Topic: Pushing Push API to CR 23:11:41 friendly reminder about multi-origin web apps with Lu Huang! :) 23:12:23 martinthomson: For testing, we could specify a web driver API to have the browser generate fake subscriptions. 23:12:36 ... API could also include an endpoint for generating fake messages for those subscriptions. 23:12:41 ... That's a lot of work. 23:13:01 marcosc: Need to balance that work vs. the cost of interop issues. 23:13:28 martinthomson: I suspect that Firefox and Chrome aren't very compatible and we will discover more issues as iOS comes up. 23:14:27 gsnedders: What are the bits that make testing challenging? 23:16:25 martinthomson: Different browsers treat service worker activation differently. E.g. Chrome enforces that you must open a notification. Firefox enforces a limited number of notifications. 23:17:49 reillyg: The communication between the browser and push service is not specified. 23:18:01 jsbell has joined #webapps 23:18:04 martinthomson: Especially on mobile browsers the push channel must go through the OS. 23:18:27 ... I think we can make the web driver model work but I'm not voluteering. 23:19:11 gsnedders: I don't know how people test this for native mobile apps. 23:19:19 martinthomson: You could probably mock it within your application. 23:20:10 present+ 23:21:10 Topic: Web Share 23:21:11 present+ 23:21:31 scribe- 23:21:43 scribe- martinthomson 23:22:04 scribe+ 23:22:07 Topic: Web Share 23:22:35 Web Share is well supported cross browser (shows support stats to the group) 23:22:48 One open Issue: permissions policy 23:23:00 Issue #169 23:23:00 Sorry, but no Tracker is associated with this channel. 23:23:39 This is about blocking third-party content from sharing. Needed to change the policy to allow all. 23:23:58 Permissions policy is a simple, but powerful API. 23:24:14 The OS sends shared stuff through a parser, which is an attack vector 23:24:34 One successful attempt was sharing a file: URL that sniffed passwords 23:25:02 We tried to get YouTube's attention, but failed. They must have put a try...catch block around the code by now 23:25:06 q+ 23:25:47 smaug: Mozilla has an intervention 23:26:17 jsbell: We have reached out to YouTube internally, they say they fixed it. 23:26:26 marcosc: Twitter has shipped the fix 23:26:50 smaug: I assumed if Google changed their code, everyone would follow 23:27:08 marcosc: To minimize the breakage, can we come up with a sensible timeline on the Chromium side 23:27:14 jsbell: We remain optimistic 23:27:51 ericwilligers: Troubleshooting with Youtube is happening 23:27:58 marcosc: Great news 23:28:12 ...There won't be a time frame, but happy to stay on it. 23:28:38 ...Hoping for involving Igalia to patch this up for WebKit and for Chrome too 23:29:14 Next issue: #108 on canShare() not being future comaptible 23:29:33 marcosc: The problem is a bit of an oversight. [Describes what the API does.] 23:30:32 ...Issues that were overlooked: the browser reports falsely that it may support when one item of the list can't be shared. 23:30:51 ...We have proposed a number of solutions, but none got implemented 23:31:15 marcosc: Comments? None. 23:31:43 ericwilligers: [Rephrases the problem.] We knew about it, and it was a test that would fail. 23:31:46 BANANAS! 23:32:08 marcosc: That's a good point. We could take the dictionary, destructure it, and try one by one. 23:32:48 marcosc: We could see if people complain. 23:33:36 marcosc: [Shows the code that would be required for testing one by one.] 23:34:00 marcosc: Would anyone object if we move the spec forward given this known flaw. 23:34:07 ...Not feeling strong about it. 23:34:19 marcosc: Igalia feels strong about it. 23:34:42 smaug: Might want to add telemetry to see this is a problem in practice. 23:35:00 ...We can change the spec to accept type: any 23:35:09 marcosc: It takes an object 23:35:19 smaug: It would iterate on all the properties. 23:35:32 marcosc: Anyone willing to do that? 23:35:57 smaug: I wonder if this would get enough usage. Only in Nighlty. 23:36:06 marcosc: Might be beta only on Windows 23:36:20 marcosc: Let's take it offline 23:36:36 ericwilligers: If canShare() is contentious, we could move it to a future level 23:36:47 marcosc: Seems fixable, to turn it into an object 23:37:12 marcosc: Don't think moving it to a different level would work, since it's already out there 23:37:54 tomayac: Does it look at file types, or also sizes? 23:38:07 marcosc: Looks at several aspects. 23:38:33 tomayac: It's not a guarantee. 23:38:53 gsnedders: We can take the canPlay() approach 23:39:00 ...Joking. 23:39:09 ericwilligers: Chrome checks the file type 23:39:19 marcosc: Correct, there are tests for that 23:40:17 marcosc: Shoutout to Microsoft for implementing it on Edge. Different from what Safari does. Should come to macOS Chrome, too. 23:40:26 ...Nice to see competition! 23:41:09 scribe- 23:41:30 TOPIC: multi-origin scopes for web application 23:41:38 scribe: Marcosc 23:41:52 diekus has joined #webapps 23:42:14 I've passed the good feedback about Web Share on macOS to the team. appreciate that Marcos! 23:42:14 LuHuang: we don't have a spec right now. We havre an explainer. Trying to solve the problem of web apps being limited to a single origin. 23:42:18 https://github.com/WICG/manifest-incubations/blob/gh-pages/scope_extensions-explainer.md 23:42:39 Daniel: do you have an example? 23:42:45 tomayac: Slack would be one 23:43:37 LuHuang: anything with a sub-domain would be one... also wikipedia (en.wikipedia.org) ... and TLD+ ones on different sub-origins 23:44:28 LuHuang: there is a case for web app window where the app needs to go to another site to, for example, show a log in prompt 23:45:20 MC: so, naturally the problem this violates the web security policy... like, what happens to permissions and storage buckets. 23:46:08 q+ 23:46:28 LuHuang: the explainer has a proposal for apps to handshake.... 23:46:50 MC: would the permissions transfer over ... what about storage? 23:47:00 LuHuang: no, that's not part of the proposal 23:47:10 LuHuang: it's not something similar as first party sets 23:47:56 LuHuang: we are talking about in the context of web apps and some of the tasks are part of the same app even though the task expands across origins. 23:48:22 q- 23:48:32 q- ericwilligers 23:48:43 https://web.dev/pwas-on-oculus-2/ 23:48:50 https://developer.oculus.com/documentation/web/pwa-gs/#scope-and-scope-extensions 23:48:50 `ovr_scope_extensions` 23:49:33 tomayac: oculus has an extension spec .... this would not be great. They have extended it with "ovr_"... this exists. 23:50:49 mc: we have known about this problem for a while, but yes we should.trty to address it. 23:51:48 mc: let's try to further understand or gather the use cases for what people are trying to do. 23:52:13 LuHuang: shortened URLs are another use cases 23:52:36 LuHuang: example with twitter -> t.com 23:53:14 LuHuang: you really need to declare these ahead of time because you can't just navigate around 23:53:48 LuHuang: this is useful for OS-based URL handling. 23:54:10 dmurph: this is different from declarative link capturing 23:55:19 LuHuang: For example you are sending a short URL, the user clinks on the shorten link, then the app should be able to handle the shortened link. 23:56:01 LuHuang: the proposal allows you do this 23:56:51 MC: LuHuang, could you please file a standards on WebKit? we can try to take a look 23:57:06 LuHuang: it would be great to know if there are any objections or things we can fix 23:57:32 mc: I've not yet looked at it, but opening the floor to other. 23:57:36 Thanks Marcos lovely to see you at Webkit <3. I'm a fan. 23:57:59 <3 23:58:31 http://github.com/webkit/standards-positions 23:58:52 @marcoscaceres 23:59:26 MC: I'll pick this up on the webkit side