Tess: reading explainer, you need a lot of context, assumes you know a lot

Hadley: nothing on user need

Lea: use cases also assume context

Ken: found it very confusing.. and the repo has other proposals.. commented for that

Lea: i can think of cases where this is user hostile. Google maps on mobile, the native app doesn't let you open multiple tabs and compare different routes. If you click on a google maps link it overrides what you already have open. It looks like this is trying to emulate this behaviour on pwas as well. I think there are many cases where that behaviour is not desirable

Ken: is in other cases. Every time I open Teams... super annoying. On the web it puts you in control, right click open in another tab is going to work

Tess: but does it? if I click on a maps ink maybe my browser opens in a new tab or maybe it gives the same bad behaviour Lea described

Ken: should make it clear that right clicking open in a tab should be followed, not use this infrastructure. Should be only for a regular click.

Tess: I thin kyou're right, there needs to be explicit mitigation. Lea's broader point is worth expressing - this feels like taking some of the hostile behaviours of native platforms and making the web as hostile as native

Lea: users dn't just click on links in a browser. In a email client, how would you open a new tab?

Tess: yep. I have a maps thing that I've installed and I click on a link and then state is blown away. They do have an example of a music player. That's a good example. If I click on a play a song thing people want that to play instead of the song I'm currently listening to

Lea: but do you want to lose your state in the other song?

Tess: good quesiton

Ken: it's not navigating

Tess: it's the same as the maps app.. opens my existing music player which is already playing something and blows away the old thing.. how do I go back to what I was doing? Maybe I had a playlist? But I click on a song in another app and there's no way to get back to my history

Ken: you can configure this. Configure existing client.. don't know if that's replacing it or adding a new history entry. navigateexistingclient.. assume it adds another history so you can go back to where you were. That would be my guess but good to get that clarified. There isthe option to use this api where you're not replacing the existing client, gets an event that someone tried to load this new url and you can act on it, that's the consumer api. I don't see how the existing client works.. what event do you get?

Tess: mod params get queued into launch queue

Ken: hw do you know it's changed? Oh so it's always called...

Tess: I like that part of the design, it's well done. Lea's underlying point stands

Ken: replacing the existing client api

Tess: this is a great example of the race to make the web equal to native without realising that the web has unique properties. This might be a feature that making the web as bad as native as opposed to equivalent functionality

Ken: the only thing I disike is replace existing cient. If it added a way that you can intercept a new url loading and you can act as a nice way in an app. S you don't lose your state. Like if you click a song, like youtube asks if you want to play a song or addi tto a playlist.

Tess: The app has to do that. Most apps don't. What Lea is saying.. what we see on native platforms, the app author doesn't do that.

Ken: you have an api here, you're opting in as an app devleoper. You have to set the route to this feature, and to set a consumer. If you dn't do the right thing you can't trust the app at all

Tess: why should we help app developers be bad..

Lea: if we don't help them they might move to native....

Ken: i find it annoying clicking on a link and music is launching in another spotiify instance.. i would like it to focus it and ask if i want to play it now or put it on the playlist. I don't like the reloading, I hate that on mobile. I'm watching so enews and click on soething else andwhat I was doing is gone and no way to get back to it. What URL was it? That is very hostile on android.

Lea: I can see that point as well. I've often been annoyed at things opening new windows for every single thing.. compared to native app.. on the other hand I also don't want to lose my current state

Ken: if we forget about new client.. it allows the app to do that. It allows the api to say I'm going to handle this, and set a consumer. Consumer gets the new url and they can decide, save state, if they do it right

Tess: my cocnern is that's not the default. Suppose this was an extension of the history api. The app can push and pop state.. the browser would do the right thing without the app developer having to do anything

Ken: how people design these single page apps is going to be worse. Then they're not going to handle it, and their framework is not going to handle it. IN that case it's going to be easier for them to handle it and say they're doing another view.

Lea: pwas don't have a back button

Ken: they can... on android... at OS level I can always..

Lea: specific to android

Ken: on windows now.. time bar..

Tess: respond with worries and excitements... Lea's example of blowing away state in eg. a maps app. Maybe you need that in some cases. We said this explainer is written for people who already know what it's about.

Lea: I can comment

Rossen: the throwaway state... state handling is very application specific. I'm not sure we can or should generalise here.

Hadley: nothing wrong with saying to implementers you might want to consider very carefully what you're doing with the state

Rossen: best practice guidence is always welcome. From an API point of view, state management is very application specific. So I agree with the point, I'm just not sure in general what else can be done besides saying do better.. To me this is a pretty generic warning that is very inactionable. It's almost a comment for the sake of a comment.

Ken: i think they can remove navigate new client. If people want that they can add a consumer that reloads. You can reload from the DOM.

Rossen: from capability point of view, some things that are not obvious to me.. this is written in a pretty contextualised way... how do you deal with multiplicity. If I have 3 different mail client apps and I click a mailto link which do I click? Is it contextual based on where it starts from? Starts from a browser vs slack app vs twitter app... always the same? does it stay?

Tess: depend on platform? One case is I could be in some map application and tap inside mail app it probably knows to handle it itself.. other case is you're in some other app and its almost always the system default.. there's some underlying platform

Rossen: that was my expectation..

Tess: they don't say that. That's the status quo in the world (maybe) but that's nt in the explainer. They should add it..

Rossen: the scenarios here are I fall back to system defaults in which case there is a file handler registered somewhere that's going to go and handle it correctly... is this the same if I have the second mail app open? My web mail app open? Would that same experience happen? It's unclear to me. Other question around breaking out of this... on one side I agree with having control of an in app experience as much as it makes sense, at the same time breaking the ability to have multiplicity here bothers me. So we should add these comments?

Tess: a bunch of comments... I'll do the one about the explainer assumptions

Rossen: I'll comment about being explicit in terms of behaviour about default file handling. Related proposals that they list here.. are these mentioned becuase they're complementary, or because they're similar but different... they are related how? Do I have to go and read all of these?

Draft comment:

Hi @alancutter,

We looked at this today during our virtual f2f. @hober and @kenchris have already relayed some of our questions above.

Bigger picture, one of our concerns is that this facilitates user hostile behavior, where new content entirely replaces old content and the user loses their current state.

For example, consider the native Google Maps application. Clicking a maps link from anywhere else *replaces* your current state with no means to retrieve it or toggle between the two (e.g. to compare routes). Even in the music player example, does the user desire for their state to be entirely replaced, or merely for the previous song to be paused?

We understand that it *is* possible to maintain the previous state with custom coding, but we are concerned that the easiest, most straightforward thing to do is what most native apps do, which is to entirely replace user state. We'd love it the Web could do better.

What are your thoughts about how to address this?

re-assigned and put on agenda for next week

Dan: Looks like they have raised at least one issue based on our feecback so far.

Max: I have several comments. Explainer should have more use cases from user perspective. This mechanism is more generic and should also consider how to use this mechanism in other proposals, like mini app. Related but not identical. They need to do some analysis to see whether this can be used in mini apps.

Sangwhan: can we ping the mini app people and see if it works for them?

Max: that is a good proposal

Sangwhan: their lifecycle management and window document in general is nonstandard. It's likely it's not going to work but..

Dan: it's in flux, we've been inputting, our review of miniapp lifecycle is still open

Sangwhan: everything that is how they do browsing context management is different frm what we expect it to be, and how they do origins. Maybe pass it onto them to take a look at and let us know if it doesn't work for them.

Dan: Max, do you think you can leave a comment asking about the use case descriptions, and the feedback you mentioned?

Max: okay

Dan: who can ping mini app?

Max: I can also do that, I'm also assigned to review lifecycle

Hadley: we had asked them to redo their explainer and put it in our format and make it a bit more .. it was really in the weeds and assuming a lot of knowledge already about the subject. They have done a fair amount of work in redoing the explainer, but I agree it needs more work on the use cases. Should acknowledge that they've already done some work. The other thing I'd like to do.. Lea and I had talked about the dangers of using webapp launch handler to open something that was already active and losing state. Example in the issue was if you have google maps open and you're already looking at something, or you have a music player open, and you launch something else based on that, will launching it overwrite what you were doing and how do you get that back, and what do we do about it going against what users expect. The group opened an issue which has activity. I'd love to have Lea get back into that and review their issue and see whether she's happy with the progress. Be nice to say we're happy and leave it to them.

Dan: lets try and do that at the plenary. I can put that into slack.

Hadley: waiting for responses

Dan: response from alan looks good - maybe we should close?

Hadley: explainer seems quite a bit clearer. We asked for changes twice. I feel like Max and Lea also had feedback on it. Largely looks like they have addresssed everything we put out there. And looks like Alan was saying we suggested they look at how it relates to miniapp lifecycle, filed an issue hoping they'd look at that together .. comment saying its worth considering look at how they fit together

Dan: I think it's related to what we were talking about earlier..

Hadley: open question of how involved we want to be.

Dan: out of scope for this particular issue.

Hadley: close with an explicit comment about the groups working together

Sangwhan: tagging Angel seems like a good way forward

Dan: drafts comment

Dan: if we close this issue, can we take the conversation to our miniapp lifecycle issue?

Sangwhan: I think so