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