IRC log of webapps on 2022-09-13

Timestamps are in UTC.

00:00:00 [reillyg]
00:00:24 [marcosc]
RRSAgent, make minutes public
00:00:24 [RRSAgent]
I'm logging. I don't understand 'make minutes public', marcosc. Try /msg RRSAgent help
00:02:34 [PenelopeMcLachlan]
<deletes astrology apps>
02:23:54 [Linux_Kerio]
Linux_Kerio has joined #webapps
04:40:57 [Guest85]
Guest85 has joined #webapps
06:28:57 [AramZS]
AramZS has joined #webapps
08:30:02 [Github]
Github has joined #webapps
08:34:05 [bluepenquin]
bluepenquin has joined #webapps
08:34:05 [EllaGe]
EllaGe has joined #webapps
08:34:06 [PenelopeMcLachlan]
PenelopeMcLachlan has joined #webapps
08:34:06 [JakeArchibald]
JakeArchibald has joined #webapps
08:34:07 [GlennHartmann]
GlennHartmann has joined #webapps
08:34:07 [MikeWasserman]
MikeWasserman has joined #webapps
08:34:08 [rego]
rego has joined #webapps
08:34:09 [PeterConn]
PeterConn has joined #webapps
08:34:10 [RayanKanso]
RayanKanso has joined #webapps
16:39:34 [RRSAgent]
RRSAgent has joined #webapps
16:39:34 [RRSAgent]
logging to
16:40:40 [dmurph]
16:40:48 [dmurph]
Currently discussing candidate recommendation issues:
16:41:01 [dmurph]
topic: Candidate recommendation
16:41:41 [dmurph]
looking at how to specify scope recommendations, same - origin web apps, etc:
16:41:52 [dmurph]
16:41:52 [trackbot]
Sorry, but no Tracker is associated with this channel.
16:42:16 [dmurph]
reillyg: Safari seems to maybe partition storage etc so having different apps on same origin are actually isolated
16:42:21 [etienne]
etienne has joined #webapps
16:43:00 [dmurph]
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 [dmurph]
... there are also tests still to write around scopes
16:44:29 [dmurph]
Next issue:
16:45:03 [dmurph]
tomayac: People can easily lock themselves out because some implementations don't include the back button in 'standalone'
16:45:14 [dmurph]
... the old Edge had a back button in Standalone
16:45:42 [dmurph]
... 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]
dmurph: The feature is in navcontrols:
16:46:56 [dmurph]
... proposed in
16:47:29 [dmurph]
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 [dmurph]
... webkit has a proprietary window.standone property
16:48:25 [dmurph]
marcosc: This tell you if you have been added to the homescreen or not
16:48:44 [dmurph]
tomayac: navigator.standalone
16:50:53 [dmurph]
dmurph: is this solved by the media queries? display-mode and navigation-buttons?
16:51:03 [dmurph]
tomayac: we have only speced the media query for back button
16:51:28 [dmurph]
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 [dmurph]
tomayac: There is also a getRelatedApplications API, so the developer can know, say, if the Android/native app is installed already
16:52:19 [dmurph]
... so they know they don't need to pitch installation
16:52:53 [dmurph]
marcosc: There is a meta tag for WebKit, it knows that the app is installed on iOS, so it opens directly.
16:55:08 [dmurph]
... what is the stance on whether we need to bring back this thing or not
16:55:42 [dmurph]
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]
dmurph: Penny how do you feel about adding this? something like adding 'is installed'?
16:59:24 [dmurph]
PenelopeMcLachlan: It seems like the media query solves this?
17:00:02 [PenelopeMcLachlan]
17:00:13 [JakeArchibald]
17:00:45 [dmurph]
tomayac: The media query should show all information from the @media display-mode feature, and navigator.standalone doesn't add anything
17:02:09 [dmurph]
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 [dmurph]
tomayac: mdn makes it pretty clear to not use navigator.standalone
17:05:00 [ri_]
ri_ has joined #webapps
17:05:14 [Guest85]
Guest85 has joined #webapps
17:05:17 [dmurph]
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 [dmurph]
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 [dmurph]
christianliebel: So based on discussion, and because Edge no longer has a back button here, we can close this.
17:07:22 [LuHuang]
Could we also take some time today to look at multi-origin scope - After lunch is fine.
17:08:18 [dmurph]
Next issue:
17:08:37 [dmurph]
17:08:47 [dmurph]
LuHuang: Can you add it to the agenda wiki doc?
17:08:49 [gsnedders]
gsnedders has joined #webapps
17:09:14 [dmurph]
17:09:17 [dmurph]
17:09:19 [dmurph]
17:12:12 [dmurph]
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 [dmurph]
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 [dmurph]
marcosc: This pull request seems reasonable:, looking at it now
17:15:41 [dmurph]
marcosc: That seems fine, it just needs to be rebased and we should check over what Ben Francis said
17:16:47 [dmurph]
action: perhaps ask mgiuca@ to rebase
17:16:47 [trackbot]
Sorry, but no Tracker is associated with this channel.
17:17:27 [dmurph]
Next issue:
17:22:16 [xiaoqian]
xiaoqian has joined #webapps
17:24:22 [dmurph]
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 [dmurph]
Next issue:
17:25:48 [dmurph]
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]
dmurph: So how to we resolve this then? Where do we connect this?
17:28:08 [dmurph]
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 [dmurph]
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]
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 [dmurph]
marcosc: Yes
17:30:50 [dmurph]
17:31:43 [marcosc_]
RRSAgent, make minutes
17:31:43 [RRSAgent]
I have made the request to generate marcosc_
17:32:07 [xiaoqian]
RRSAgent, make log public
17:37:16 [AramZS]
AramZS has joined #webapps
17:46:25 [AramZS]
AramZS has joined #webapps
17:49:04 [xiaoqian]
RRSAgent, make minutes
17:49:04 [RRSAgent]
I have made the request to generate xiaoqian
17:52:17 [xiaoqian]
meeting: TPAC 2022 WebApps WG meeting
17:52:26 [xiaoqian]
chair: marcosc, tink
17:54:02 [xiaoqian]
s/<deletes astrology apps>//
17:54:07 [xiaoqian]
RRSAgent, make minutes
17:54:07 [RRSAgent]
I have made the request to generate xiaoqian
18:05:31 [tantek]
tantek has joined #webapps
18:05:39 [tantek]
18:08:11 [dmurph]
18:08:16 [marcosc]
marcosc has joined #webapps
18:08:35 [dmurph]
topic: App Identity Updating w.r.t. images (manifest version, token, per-image token, etc). Doc:
18:08:42 [marcosc]
TOPIC: Updates
18:12:16 [dmurph]
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 [JakeArchibald]
dmurph (IRC): we could have a version token in the manifest
18:13:05 [JakeArchibald]
dmurph (IRC): we will show a 'reinstall' like dialog, showing the old and new
18:13:41 [JakeArchibald]
JakeA (IRC): This is to stop apps changing to look like your bank?
18:13:47 [JakeArchibald]
dmurph (IRC): yes
18:14:06 [JakeArchibald]
dmurph (IRC): whenever they want their images to change they update their token
18:14:17 [JakeArchibald]
dmurph (IRC): another way is manifest URL change
18:14:34 [risako]
risako has joined #webapps
18:14:46 [diekus]
diekus has joined #webapps
18:17:50 [jsbell]
jsbell has joined #webapps
18:22:03 [PenelopeMcLachlan]
18:29:28 [dmurph]
Lots of discussion about: 1 we could just require url to change, 2 we could use fancy image diffing algorithms ...
18:29:41 [dmurph]
3 having a version token
18:30:28 [dmurph]
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 [dmurph]
PenelopeMcLachlan: Is it worth prompting 5 million old users for a 5 pixel change in my logo?
18:31:31 [dmurph]
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 [dmurph]
... one of the things users like about the update process is that the new version has new stuff for them
18:32:14 [dmurph]
... 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 [diekus]
This is the explainer mentioned by Penelope:
18:32:40 [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:32:44 [JakeArchibald]
Penelope McLachlan: apologies for not following the queue
18:33:30 [dmurph]
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 [dmurph]
marcosc: That issue might be out-of-scope - maybe get a better CDN?
18:34:09 [dmurph]
reillyg: You can roll out the new icon first, test it, and then update the manifest version
18:35:08 [dmurph]
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 [dmurph]
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]
dmurph: App updates are also not as foreign a concept as serviceworker update - users & developers are familiar with app updates
18:37:49 [dmurph]
tomayac: The mini apps have a same thing here with a version field, semantic versioning & ordering.
18:37:59 [dmurph]
marcosc: We don't want to do that
18:39:28 [dmurph]
tomayac: What about apps that are never navigated or reloaded?
18:39:54 [dmurph]
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 [dmurph]
... maybe at 3am you could do a check in the background?
18:41:20 [dmurph]
dmurph: Might be weird because you need the document linking the manifest to parse & load the manifest
18:41:38 [dmurph]
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 [dmurph]
marcosc: Yes, for privacy reasons, we don't want to update name & icon here
18:42:04 [dmurph]
... if a short name changes, is that enough of a signal w/o a version token change as well?
18:42:20 [dmurph]
... or should we treat the version token change as the only signal for a true update
18:42:46 [dmurph]
... We could do both
18:43:15 [dmurph]
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 [dmurph]
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 [dmurph]
marcosc: Fair. It does no real harm to change url and add fragment identifier at end of images
18:46:19 [dmurph]
tomayac: What about manifests that might have this field already?
18:47:25 [dmurph]
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 [dmurph]
reillyg: Also prevents you from updating image technologies
18:49:14 [dmurph]
Evan Stade: Does this mean we want all silent fields to also not update until version token changes?
18:50:10 [dmurph]
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 [dmurph]
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 [dmurph]
marcosc: You can remove yourself by removing version token later too
18:51:38 [dmurph]
PenelopeMcLachlan: I like that
18:51:52 [dmurph]
dmurph: To clarify - without version token, images are only considered to be changed if url is changed
18:52:12 [dmurph]
... but if you have version_token, then nothing changes unless you change that
18:52:27 [dmurph]
JakeArchibald: Seems fine to me
18:53:15 [dmurph]
JakeArchibald: This sounds like etag
18:53:31 [dmurph]
... this is a caching header
18:55:25 [dmurph]
dmurph: What about the edge between non-version token and version token?
18:56:40 [dmurph]
JakeArchibald: If the version token changes but nothing else has changed, then don't show update
18:57:49 [dmurph]
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 [dmurph]
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 [dmurph]
marcosc: It might be good to force the update then
18:59:13 [dmurph]
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 [jsbell]
18:59:31 [dmurph]
Evan Stade: Hoping that the user wouldn't see that change if there isn't a visible change.
19:02:30 [dmurph]
dmurph: We will always false-positive trigger icon bitmap changes for certain sites
19:03:13 [jsbell]
19:03:20 [PenelopeMcLachlan]
19:03:41 [dmurph]
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 [dmurph]
... even with the token.
19:04:11 [dmurph]
tomayac: What about removing the version_token tag?
19:05:35 [dmurph]
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]
estade has joined #webapps
19:06:14 [dmurph]
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 [jsbell]
19:06:25 [JakeArchibald]
19:07:04 [marcosc]
19:07:33 [dmurph]
dmurph: We could have sentinel that users can specify as initial version if they don't want to trigger update
19:08:16 [dmurph]
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 [dmurph]
JakeArchibald: If we require change to the icon url, then users getting the fresh version would NOT get the update
19:10:04 [dmurph]
reillyg: Starts to get annoying to dev, but seems to be necessary
19:10:34 [dmurph]
... 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]
xiaoqian has joined #webapps
19:11:51 [dmurph]
action: dmurph follow up with alancutter & Penny about this discussion, come up with scenario table, conclusion proposal.
19:11:51 [trackbot]
Sorry, but no Tracker is associated with this channel.
19:12:11 [dmurph]
marcosc: Would be great to re-use beforeinstallprompt
19:13:47 [dmurph]
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 [dmurph]
PennyMcLachlan: Interested in talking about making navigator.install (declarative install) and deprecating beforeinstallprompt. Idea - no doc or anything
19:19:40 [dmurph]
marcosc: For other apis, like permissions, we have added a webdriver. We could do it there.
19:20:37 [dmurph]
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 [dmurph]
... maybe this should be something that is more in the user's control and not developer's control
19:21:32 [dmurph]
... 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 [dmurph]
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 [dmurph]
... Where it gets tricky is having the web site have control over the install prompt. "Install our app".
19:22:49 [dmurph]
... `beforeinstallprompt` addresses that problem in a fairly elegant way. So delicate balance there.
19:23:15 [dmurph]
... I would probably push back on `navigator.install`, even if behind button
19:24:07 [dmurph]
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 [JakeArchibald]
19:24:43 [dmurph]
... 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 [dmurph]
marcosc: I get this, these smarts are great, but really challenging. Pre-supposes a bunch of smarts.
19:25:27 [dmurph]
... Safari's perspective - the user is in control, we don't really care about installability signals.
19:25:52 [dmurph]
PenelopeMcLachlan: I would love developers to be able to participate in install actions similar to other app ecosystems.
19:26:19 [dmurph]
... the users currently still need to seek in the browser UI itself and display help text.
19:26:54 [dmurph]
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 [dmurph]
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 [dmurph]
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 [dmurph]
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 [dmurph]
marcosc: We gave you beforeinstallprompt, and there is enough signal that we can now offer you this API
19:30:06 [dmurph]
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 [dmurph]
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 [dmurph]
PenelopeMcLachlan: Complicated set of tradeoffs here, appreciate the discussion.
19:32:02 [xiaoqian]
RRSAgent, make minutes
19:32:02 [RRSAgent]
I have made the request to generate xiaoqian
19:49:01 [hartmanng]
hartmanng has joined #webapps
20:20:31 [AramZS]
AramZS has joined #webapps
20:35:13 [bradley]
bradley has joined #webapps
20:44:02 [Guest85]
Guest85 has joined #webapps
20:45:54 [jsbell]
jsbell has joined #webapps
20:46:45 [dmurph]
20:46:57 [dmurph]
topic: How do we make the working group more effective?
20:47:00 [jsbell]
20:47:06 [scheib]
20:48:59 [dmurph]
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 [dmurph]
... 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 [dmurph]
... 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 [dmurph]
... We should care about IPR commitments.
20:50:46 [dmurph]
.. We used to have 20 specs, now there are less. Trying to get them down & be more manageable.
20:51:25 [dmurph]
... Do we kill the working group? Do something new? The name 'WebApps' is good, so that is good.
20:52:12 [dmurph]
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 [dmurph]
... we should always be in a growth mindset.
20:52:38 [hakan]
hakan has joined #webapps
20:53:06 [dmurph]
... 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 [dmurph]
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 [dmurph]
... in 2019 there was a ton of interest in IndexedDB, that was great
20:54:43 [dmurph]
... 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 [dmurph]
tomayac: What does "web app" mean? Progressive web app? Run in browser tab? Standalone?
20:55:04 [reillyg]
20:55:23 [dmurph]
... is this something that we are not comfortable on the web? Or do we want to force a store download? etc
20:56:05 [dmurph]
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 [dmurph]
... 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 [dmurph]
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 [dmurph]
... html, for example, could encompass every single spec.
20:57:57 [dmurph]
... One end case is to put all into html spec? Or is that not how we do things?
20:58:18 [dmurph]
.. If not, we are going to need some group charter with a scope of maintaining specifications in this area.
20:58:48 [dmurph]
marcosc: HTML gives us hooks into things that we use, like url parsing. Gamepad, attaching to navigator for instance.
20:59:12 [dmurph]
Charter is here:
21:00:09 [dmurph]
Oli: UI Events have been around forever. IndexedDB is very core. Some of kind of the 'edge' of the web.
21:00:30 [dmurph]
marcosc: I like the idea that input events could be the own thing. Database & storage could be their own thing.
21:00:51 [dmurph]
Oli: And maybe some things would have priority?
21:01:16 [dmurph]
marcosc: Interesting with priority, maybe, for example, we put more resources between UI Events because it's so important
21:02:25 [estade]
estade has joined #webapps
21:03:33 [dmurph]
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]
tantek has joined #webapps
21:03:47 [dmurph]
marcosc: What should we then change? Should we change our working mode? Should we have more meetings?
21:04:36 [dmurph]
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 [dmurph]
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 [dmurph]
... spec's orgs? Maybe not.
21:07:32 [dmurph]
21:07:41 [reillyg]
21:08:10 [dmurph]
dmurph: It would be great to know what could happen. What are some imaginary options?
21:10:18 [garykac]
garykac has joined #webapps
21:10:44 [dmurph]
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 [dmurph]
... but it doesn't have to be regular.
21:11:20 [garykac]
21:11:28 [dmurph]
marcosc: Who can commit more time for some of these?
21:13:47 [dmurph]
marcosc: Happy to have feedback, now or in the future. Chair rotation, editor rotations, meetings, etc
21:14:02 [dmurph]
Gary: Are there restrictions with meetings and announcing attendance?
21:14:30 [dmurph]
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 [garykac]
21:16:10 [dmurph]
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 [RRSAgent]
I have made the request to generate xiaoqian
21:29:00 [dmurph]
topic: Manifest Override
21:29:05 [dmurph]
21:29:50 [garykac]
21:31:06 [garykac]
dmurph: discussion of how MediaQueries works
21:31:14 [garykac]
In this proposal
21:31:22 [garykac]
main thing is dealing with darkmode/lightmode
21:31:42 [garykac]
when app is launched, mode is extracted from media query.
21:31:57 [garykac]
(1) what do we want to support in general
21:32:05 [garykac]
(2) how to we get this to run on startup - on launch
21:32:21 [garykac]
eg: on launch logic happens that checks background color
21:32:32 [garykac]
what other impl options?
21:34:02 [dcrousso]
dcrousso has joined #webapps
21:35:19 [garykac]
on launch, we need to know what css media features are supported.
21:35:35 [garykac]
media queries are primarily about the device
21:35:50 [garykac]
there are a few about the browser, but most are about the device
21:36:19 [garykac]
eg: multiple displays, one supports a color space, while the other one doesn't
21:37:27 [garykac]
???: we could recycle for format of media queries, but not support everything.
21:37:31 [garykac]
why not?
21:37:46 [garykac]
supporting everything is hard. partially because the app hasn't yet launched.
21:38:03 [reillyg]
21:38:27 [reillyg]
21:38:54 [garykac]
browser needs to figure out the media query. race condition between launching and getting result of media query.
21:39:55 [garykac]
we could store the manifest info in a plist for the native
21:40:17 [garykac]
what if screen geometry changes - a new monitor is added?
21:40:22 [garykac]
theh stored plist would not be updated.
21:40:39 [garykac]
???: plist is same as manifest (at launch)
21:40:47 [garykac]
louise: need an entire parser for this
21:41:36 [garykac]
reilly: concern: we provide a filtering lang - look for device with these properties
21:41:53 [garykac]
then we need to translate that filtering into whatever the native platform needs
21:42:12 [garykac]
we can make it work by asking for all devices and doing out own filtering
21:42:32 [garykac]
but huge space of expressible queries that are not translatable into native formats.
21:42:39 [garykac]
what is the fallback in that case?
21:42:44 [garykac]
say it's not supported?
21:42:58 [garykac]
not a satisfying experience.
21:43:09 [garykac]
eg: something expressable on iOS but not on Android
21:43:21 [garykac]
we need to be careful about what we sa we support
21:43:29 [garykac]
???: don't we have this already today?
21:43:49 [garykac]
same situation: one is in the OS but the other is in the browser.
21:44:07 [garykac]
people need to test these things to make sure they work in the scenarios they care about.
21:44:29 [garykac]
eg: iOS can't necessarily support requests for dark mode variants
21:44:40 [garykac]
but other platforms could possibly support that
21:44:56 [garykac]
reilly: we'll need a set of examples so we can explore this
21:45:15 [garykac]
what we have here is a browser mediated interface to the native platform
21:45:23 [garykac]
and that can cause problems.
21:45:33 [garykac]
so a set of key examples would be great
21:45:57 [garykac]
marcosc: we acknowledge that it's a big "ask"
21:46:12 [garykac]
but we already have this language (Media Queries)
21:46:31 [garykac]
but it does add a huge burden on the implementors
21:46:43 [garykac]
we could choose a simpler route, but that's not as powerful
21:47:31 [garykac]
??? = dcrou
21:48:08 [garykac]
marcos: reviewing some of the samples
21:48:14 [garykac]
we have an expression "16/9"
21:48:39 [garykac]
need to a parser for aspect ratio for a display
21:48:56 [garykac]
dmurph: what are the examples for where people need this aspect ratio check
21:49:25 [garykac]
devin: eg: size of icon
21:49:49 [garykac]
we also need to bear in mind future benefits of being general
21:49:58 [garykac]
dmurph: but we don't want to over engineer
21:50:35 [garykac]
dcrou: nothing about the manifest spec is limited to native apps - also used by browsers
21:51:11 [garykac]
it's basically a bucket of metadata instead of a bunch of fields.
21:51:29 [garykac]
dmurph: what is hover
21:51:47 [garykac]
dcrou: it's the primary pointing device
21:51:55 [garykac]
anyhover = any pointing device
21:52:08 [garykac]
also pointer granularity: coarse - fine
21:52:27 [garykac]
dmurph: can dev require that app can only be installed on device with certain conditions
21:52:43 [garykac]
dcrou: possibly. so we shouldn't restrict it
21:52:50 [garykac]
these are already adjustable from JS
21:53:15 [garykac]
dmurph: hard part: is this feasible to implement at startup - on splash screen on launch
21:53:29 [garykac]
marcos: it's a HUGE ask
21:53:59 [garykac]
dcrou: we've thought about pulling the Media query parser into something sharable.
21:54:23 [garykac]
dmurph: better context: engineering resource contraints
21:54:39 [garykac]
so the more specific use cases we have, the easier it is to rationalize the work
21:55:31 [garykac]
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 [garykac]
reilly: which keys from the manifest?
21:56:51 [garykac]
dcrou: mostly display related
21:58:11 [garykac]
dmurph: for things that are nested
21:58:23 [garykac]
eg: want to change icons because it's french
21:58:35 [garykac]
do we just substitute the entire icon field in there?
21:59:01 [garykac]
marcosc: have to look it up.
21:59:30 [garykac]
icons override: put the query, then put the things you want after that
22:00:03 [garykac]
louise: shortcuts
22:00:29 [garykac]
do we allow certain parts (like just the icon) of the shortcuts, or do you need to override the whole thing.
22:00:40 [garykac]
marcosc: need to have the whole thing - it's simpler.
22:01:23 [garykac]
overall: do people think this is too much? or is it worth trying?
22:01:41 [garykac]
louise: rather not commit at this time to hoisting out the parser.
22:01:52 [garykac]
would like to see more details in the spec
22:02:19 [garykac]
marcosc: to the room: DOES ANYONE OBJECT?
22:02:37 [garykac]
Webkit is willing to try it to see how it works.
22:03:05 [garykac]
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 [garykac]
schieb: we only need a few things at the moment, but the value of Media Queries is making it future proof.
22:04:35 [garykac]
dcrou: also developers are already familiar with MQs so that's convenient.
22:04:56 [garykac]
schieb: could be subset a subset of MQ?
22:05:26 [garykac]
dcrou: we can do that with this. each UA can support a subset to support.
22:05:46 [garykac]
advantage: as new things are added to MQ, they are automatically supported by this system.
22:06:29 [garykac]
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 [garykac]
elle: What other things change quickly?
22:07:40 [garykac]
prefers reduce motion, contrast, colors, ...
22:08:05 [garykac]
22:08:31 [garykac]
tomayac: what about SVG?
22:08:46 [garykac]
dcrou: doesn't work well (works on launch but doesn't update)
22:09:52 [Guest85]
Guest85 has joined #webapps
22:10:05 [garykac]
tomayac: can we reuse code from SVG
22:10:16 [garykac]
dcrou: not sure. but doesn't like current SVG behavior
22:11:28 [ericwilligers]
ericwilligers has joined #webapps
22:11:47 [garykac]
marcosc: calling time on this discussion since we're part 3:00pm
22:12:17 [garykac]
dmurph: to clarify: adding language to the spec to handle the language case
22:13:05 [marcosc]
marcosc has joined #webapps
22:13:31 [marcosc]
RRSAgent, draft minutes
22:13:31 [RRSAgent]
I have made the request to generate marcosc
22:37:23 [ericwilligers]
22:38:41 [AramZS]
AramZS has joined #webapps
22:42:33 [marcosc]
marcosc has joined #webapps
22:42:46 [marcosc]
22:43:27 [dgrogan]
dgrogan has joined #webapps
22:44:11 [reillyg]
22:44:37 [reillyg]
marcosc: We've identified that it is quite expensive to create a service worker in order to show a notification.
22:44:58 [reillyg]
... 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 [reillyg]
... Saves resources.
22:45:55 [reillyg]
... Is this something we would like to explore?
22:46:07 [reillyg]
... Is this a Javascript side of things or protocol side of things? (W3C or IETF)
22:46:34 [reillyg]
gsnedders: This is currently the common case for native apps on iOS.
22:46:44 [reillyg]
... Web apps have a greater performance and power cost for notifications.
22:46:54 [reillyg]
22:47:06 [reillyg]
q- garykac
22:47:07 [marcosc]
22:47:55 [martinthomson]
martinthomson has joined #webapps
22:47:57 [LuHuang]
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 [martinthomson]
can someone link me to context for this?
22:49:02 [martinthomson]
22:49:12 [marcosc]
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 [reillyg]
brady: We've discussed that this be registered at Push registration time.
22:51:15 [martinthomson]
22:51:20 [reillyg]
... 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 [reillyg]
22:52:09 [reillyg]
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 [reillyg]
q- martinthomson
22:53:28 [reillyg]
brady: If a site opted into a fast-track push handling we could remove the service worker.
22:54:08 [reillyg]
... The existence of service workers is a tracking vector, which is why ITP wants to unregister them.
22:56:12 [reillyg]
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 [reillyg]
... I understand the other benefits of this proposal.
22:56:50 [martinthomson]
tomayac: also confused about the ITP 7 day active usage cap.
22:57:13 [reillyg]
tomayac: I'm confused about the ITP 7 day active usage cap.
22:57:40 [reillyg]
gsnedders: After 7 days all storage, including the service worker is removed.
22:58:39 [reillyg]
marcosc: If you register for the fast path you can't do things like fetch in response to a push.
22:58:55 [reillyg]
martinthomson: In order to use the fast path you need some state to decrypt the message.
22:59:37 [martinthomson]
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 [martinthomson]
...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 [martinthomson]
...this seems more useful for the spammy uses of notifications
23:01:11 [reillyg]
scribe+ martinthomson
23:01:43 [reillyg]
gsnedders: To my knowledge the state for receiving the message it already stored outside the browser.
23:01:55 [reillyg]
martinthomson: I think that's assuming things about push notifications infrastructure.
23:03:11 [reillyg]
martinthomson: In Chrome we need state in the browser to understand the content of the message.
23:03:38 [martinthomson]
23:04:26 [reillyg]
martinthomson: This is an appealing proposal from a performance. I'm just pushing back on the ITP aspect.
23:04:46 [reillyg]
gsnedders: The larger motivation on our side is also performance.
23:06:21 [reillyg]
PeterConn: This would also allow the browser to load a page instantly when the notification is clicked.
23:06:59 [reillyg]
martinthomson: This is totally workable as long as we figure out the structure of the fields.
23:07:24 [reillyg]
marcosc: Knowing the protocol side, Martin, does this make sense to do at subscription time or in the protocol.
23:07:30 [tantek]
tantek has joined #webapps
23:08:22 [reillyg]
martinthomson: Where would the instructions for how to handle the message be stored?
23:08:27 [PeterConn]
draft explainer for what I was talking about:
23:09:03 [reillyg]
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 [reillyg]
marcosc: The Notification launchURL proposal seems like a piece of the solution.
23:11:14 [diekus]
diekus has joined #webapps
23:11:19 [reillyg]
Topic: Pushing Push API to CR
23:11:41 [diekus]
friendly reminder about multi-origin web apps with Lu Huang! :)
23:12:23 [reillyg]
martinthomson: For testing, we could specify a web driver API to have the browser generate fake subscriptions.
23:12:36 [reillyg]
... API could also include an endpoint for generating fake messages for those subscriptions.
23:12:41 [reillyg]
... That's a lot of work.
23:13:01 [reillyg]
marcosc: Need to balance that work vs. the cost of interop issues.
23:13:28 [reillyg]
martinthomson: I suspect that Firefox and Chrome aren't very compatible and we will discover more issues as iOS comes up.
23:14:27 [reillyg]
gsnedders: What are the bits that make testing challenging?
23:16:25 [reillyg]
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]
reillyg: The communication between the browser and push service is not specified.
23:18:01 [jsbell]
jsbell has joined #webapps
23:18:04 [reillyg]
martinthomson: Especially on mobile browsers the push channel must go through the OS.
23:18:27 [reillyg]
... I think we can make the web driver model work but I'm not voluteering.
23:19:11 [reillyg]
gsnedders: I don't know how people test this for native mobile apps.
23:19:19 [reillyg]
martinthomson: You could probably mock it within your application.
23:20:10 [jsbell]
23:21:10 [reillyg]
Topic: Web Share
23:21:11 [ericwilligers]
23:21:31 [reillyg]
23:21:43 [reillyg]
scribe- martinthomson
23:22:04 [tomayac]
23:22:07 [tomayac]
Topic: Web Share
23:22:35 [tomayac]
Web Share is well supported cross browser (shows support stats to the group)
23:22:48 [tomayac]
One open Issue: permissions policy
23:23:00 [tomayac]
Issue #169
23:23:00 [trackbot]
Sorry, but no Tracker is associated with this channel.
23:23:39 [tomayac]
This is about blocking third-party content from sharing. Needed to change the policy to allow all.
23:23:58 [tomayac]
Permissions policy is a simple, but powerful API.
23:24:14 [tomayac]
The OS sends shared stuff through a parser, which is an attack vector
23:24:34 [tomayac]
One successful attempt was sharing a file: URL that sniffed passwords
23:25:02 [tomayac]
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 [ericwilligers]
23:25:47 [tomayac]
smaug: Mozilla has an intervention
23:26:17 [tomayac]
jsbell: We have reached out to YouTube internally, they say they fixed it.
23:26:26 [tomayac]
marcosc: Twitter has shipped the fix
23:26:50 [tomayac]
smaug: I assumed if Google changed their code, everyone would follow
23:27:08 [tomayac]
marcosc: To minimize the breakage, can we come up with a sensible timeline on the Chromium side
23:27:14 [tomayac]
jsbell: We remain optimistic
23:27:51 [tomayac]
ericwilligers: Troubleshooting with Youtube is happening
23:27:58 [tomayac]
marcosc: Great news
23:28:12 [tomayac]
...There won't be a time frame, but happy to stay on it.
23:28:38 [tomayac]
...Hoping for involving Igalia to patch this up for WebKit and for Chrome too
23:29:14 [tomayac]
Next issue: #108 on canShare() not being future comaptible
23:29:33 [tomayac]
marcosc: The problem is a bit of an oversight. [Describes what the API does.]
23:30:32 [tomayac]
...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 [tomayac]
...We have proposed a number of solutions, but none got implemented
23:31:15 [tomayac]
marcosc: Comments? None.
23:31:43 [tomayac]
ericwilligers: [Rephrases the problem.] We knew about it, and it was a test that would fail.
23:31:46 [gsnedders]
23:32:08 [tomayac]
marcosc: That's a good point. We could take the dictionary, destructure it, and try one by one.
23:32:48 [tomayac]
marcosc: We could see if people complain.
23:33:36 [tomayac]
marcosc: [Shows the code that would be required for testing one by one.]
23:34:00 [tomayac]
marcosc: Would anyone object if we move the spec forward given this known flaw.
23:34:07 [tomayac]
...Not feeling strong about it.
23:34:19 [tomayac]
marcosc: Igalia feels strong about it.
23:34:42 [tomayac]
smaug: Might want to add telemetry to see this is a problem in practice.
23:35:00 [tomayac]
...We can change the spec to accept type: any
23:35:09 [tomayac]
marcosc: It takes an object
23:35:19 [tomayac]
smaug: It would iterate on all the properties.
23:35:32 [tomayac]
marcosc: Anyone willing to do that?
23:35:57 [tomayac]
smaug: I wonder if this would get enough usage. Only in Nighlty.
23:36:06 [tomayac]
marcosc: Might be beta only on Windows
23:36:20 [tomayac]
marcosc: Let's take it offline
23:36:36 [tomayac]
ericwilligers: If canShare() is contentious, we could move it to a future level
23:36:47 [tomayac]
marcosc: Seems fixable, to turn it into an object
23:37:12 [tomayac]
marcosc: Don't think moving it to a different level would work, since it's already out there
23:37:54 [tomayac]
tomayac: Does it look at file types, or also sizes?
23:38:07 [tomayac]
marcosc: Looks at several aspects.
23:38:33 [tomayac]
tomayac: It's not a guarantee.
23:38:53 [tomayac]
gsnedders: We can take the canPlay() approach
23:39:00 [tomayac]
23:39:09 [tomayac]
ericwilligers: Chrome checks the file type
23:39:19 [tomayac]
marcosc: Correct, there are tests for that
23:40:17 [tomayac]
marcosc: Shoutout to Microsoft for implementing it on Edge. Different from what Safari does. Should come to macOS Chrome, too.
23:40:26 [tomayac]
...Nice to see competition!
23:41:09 [tomayac]
23:41:30 [marcosc]
TOPIC: multi-origin scopes for web application
23:41:38 [marcosc]
scribe: Marcosc
23:41:52 [diekus]
diekus has joined #webapps
23:42:14 [diekus]
I've passed the good feedback about Web Share on macOS to the team. appreciate that Marcos!
23:42:14 [marcosc]
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 [LuHuang]
23:42:39 [marcosc]
Daniel: do you have an example?
23:42:45 [marcosc]
tomayac: Slack would be one
23:43:37 [marcosc]
LuHuang: anything with a sub-domain would be one... also wikipedia ( ... and TLD+ ones on different sub-origins
23:44:28 [marcosc]
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 [marcosc]
MC: so, naturally the problem this violates the web security policy... like, what happens to permissions and storage buckets.
23:46:08 [tomayac]
23:46:28 [marcosc]
LuHuang: the explainer has a proposal for apps to handshake....
23:46:50 [marcosc]
MC: would the permissions transfer over ... what about storage?
23:47:00 [marcosc]
LuHuang: no, that's not part of the proposal
23:47:10 [marcosc]
LuHuang: it's not something similar as first party sets
23:47:56 [marcosc]
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 [marcosc]
23:48:32 [marcosc]
q- ericwilligers
23:48:43 [LuHuang]
23:48:50 [tomayac]
23:48:50 [LuHuang]
23:49:33 [marcosc]
tomayac: oculus has an extension spec .... this would not be great. They have extended it with "ovr_"... this exists.
23:50:49 [marcosc]
mc: we have known about this problem for a while, but yes we should.trty to address it.
23:51:48 [marcosc]
mc: let's try to further understand or gather the use cases for what people are trying to do.
23:52:13 [marcosc]
LuHuang: shortened URLs are another use cases
23:52:36 [marcosc]
LuHuang: example with twitter ->
23:53:14 [marcosc]
LuHuang: you really need to declare these ahead of time because you can't just navigate around
23:53:48 [marcosc]
LuHuang: this is useful for OS-based URL handling.
23:54:10 [marcosc]
dmurph: this is different from declarative link capturing
23:55:19 [marcosc]
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 [marcosc]
LuHuang: the proposal allows you do this
23:56:51 [marcosc]
MC: LuHuang, could you please file a standards on WebKit? we can try to take a look
23:57:06 [marcosc]
LuHuang: it would be great to know if there are any objections or things we can fix
23:57:32 [marcosc]
mc: I've not yet looked at it, but opening the floor to other.
23:57:36 [diekus]
Thanks Marcos lovely to see you at Webkit <3. I'm a fan.
23:57:59 [marcosc]
23:58:31 [marcosc]
23:58:52 [marcosc]
23:59:26 [marcosc]
MC: I'll pick this up on the webkit side