-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change the default value for start_url #670
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm
Really? This was meant as a straw-man (to show the difficulty of having no default --- see the issue box added by this patch). Marcos expressed uncomfortability with this solution also. Let's sleep on it over the weekend. |
Yes, I wanted to say that I am OK with it, but of course you shouldn't merge it as there are still concerns from Marcos. Maybe I should have made that clear |
I am also not such a fan of making it required for the reasons you stated. But then again scope really only make sense in combination with start_url. So maybe we should make some properties dependent on others instead |
On the bug I proposed making |
It sounds like a sane default to me. But maybe some sites actually don't want their site so show up as a PWA even when using a service worker, so maybe we need a way to opt out of that |
Practically speaking, the best signal an app can provide that it doesn't want to be a PWA is Any manifest with Any manifest with |
@mgiuca wrote:
Agree. It's also why we made it the default.
That sounds good to me. |
Updated to set the default to ".". This will be a behavioural change. I'll ask internally whether people are OK with this. |
@mgiuca why will it not be installable in Chrome? What if I want the browser to show people the install banner to suggest them to put a link to my site on their homescreen, but make it "only" a link that opens in the browser, not an app without browser chrome? |
This is a great question. Ultimately, it's a product decision: Chrome doesn't want to promote browser-tab sites for "installation" because we view that install banner as a privilege granted to apps that have put in some effort towards a true app-like experience. However, this is a single browser's individual product decision; another browser could promote all sites with a valid manifest as installable, for example. So, to go back to the original question, how does a site developer opt out of receiving the PWA treatment? Well, it depends what you're trying to opt out of:
Either way, the answer is not to give developers an opt-out mechanism of leaving |
75db739
to
14b4d07
Compare
I do not have opinion on which signal we should use to determine whether a site is a PWA I think the default start_url should be the origin of the manifest Rationale: Here's an example Web Manifest in the wild which does not have a start_url (and has display=standalone) where a default start_url of "." would result in a 404. |
(I'll refer to your proposal as being that the default start_url is "/", as opposed to mine where it is ".".) Let's cover the most common cases for an app directory hierarchy:
So (a) will be covered no matter whether the default is "/" or ".", and that's the most important. A default of "/" covers (b) but not (c). A default of "." covers (c) but not (b). So I can see arguments for and against "/" and "." being the default. However, I don't think (b) is necessarily more common than (c); I'd guess they're within the same order of magnitude, with (a) an order of magnitude more common than either of them. I have two main arguments for "." over "/":
I don't think it matters particularly much, but those two reasons cause me to lean towards "." instead of "/". Finally, I don't think we should be looking at this "probabilistically" (you used the phrase "which is least likely to be a 404"). Since, at least, Chrome does not currently honour a manifest without a
Yep, that's an example of (b). But there are also lots of others of case (c), notably every PWA hosted on github.io, since your app needs to be hosted in a sub-directory (an example I just found: https://gauravchl.github.io/secure-wallet/). |
9298747
to
32ca126
Compare
Matt sorry for the earlier confusion. Chrome currently DOES honour a manifest without a start_url. If a user adds a page with a Web Manifest with no start_url to the homescreen, Chrome will currently add a shortcut to a fullscreen webapp to the homescreen and uses the document URL as the start_url |
@pkotwicz this is something I've wanted to get rid of for a long time. The right to a standalone app treatment should be reserved for PWAs only since devs have gone to the extra effort there to make a good experience. |
Yeah, in the non-PWA case, we use the document URL, but we also do that when there is no manifest whatsoever. I think we can consider that to be just ignoring the manifest, rather than honouring the current language that says to use the document URL. Note that the manifest spec says: "The |
I'm happy to go with whatever @dominickng and @mgiuca come up with here (and removing the MAY text around start url). |
I think the MAY text is helpful actually. It means we can decide to override the developer's wishes (e.g., in the case where the site is not a PWA, and we deliberately want to disrespect the manifest). However, having a specified default behaviour is useful. |
If the client can ignore the manifest as you mentioned in a previous comment, I am ok with using "." as a default start URL. I am concerned a bit that a user will add a Web Manifest to their site for a reason other than the "add-to-homescreen" behavior. (and would not have tested add-to-homescreen behavior). It feels like a bug to allow a user to use the browser to add a website to the homescreen if the start_url points to a 404 page. |
@pkotwicz this can already happen today - developers can explicitly specify a start_url that 404s. If a dev is adding a web manifest for reasons other than add to homescreen, they probably won't have met the other requirements for being a PWA, so we would ignore the start_url anyway. |
32ca126
to
d8ac494
Compare
I think the above comments by @marcoscaceres @dominickng and @pkotwicz represent sufficient consensus around the issue. I will land the change as-is on Monday (unless there is an objection here). This will be a breaking change, of sorts. Specifically:
I have added a new (temporary) non-normative note to the spec in the latest commit: "This default was changed in June 2018. Manifest authors might wish to avoid relying on the default behaviour (and explicitly specify this member), as user agents might still respect the previous default (the document URL), or ignore the manifest entirely if |
@@ -1985,13 +1990,27 @@ <h3> | |||
needs to be <a>same-origin</a> as <code>Document</code> of the | |||
<a>top-level browsing context</a>. | |||
</li> | |||
<li>Return <var>document URL</var>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed offline: this is broken for the case where you have a manifest with no start_url hosted on originA, which is a different origin to your document URL (originB). In that case, the start_url will be set to something on originA, which is still a different origin to the document URL.
We need to check the default value when creating it to make sure it is same-origin with document URL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is correct, and quite annoying as it seems we can't (yet) detach our dependency on the document URL.
I've added a new step which falls back to document URL as the default, if manifest is not same-origin as the document. This will be cleaned up once we fully detach the document URL.
66acbb7
to
1af6281
Compare
Hello Folks, |
Hi Jeff, When you say the "app package name", do you mean that's the unique identifier for the app? This spec doesn't really have an opinion about what is the "unique key" for the app (though maybe it should). This proposal is more about just what is the Aside: I think the best thing to use as a "unique key" is the manifest URL itself, not the start URL or origin. While it's unlikely that two apps will share the same start URL, they can. And it's certainly possible for two apps to have the same origin (e.g., all apps for a single user under github.io). I don't think you should be using the origin when the I guess pertinent to this PR, what is the default page that you open for sites that have no |
9321478
to
481f44b
Compare
Matt, We are on the same page. Our package name is basically a generated GUID that the dev has no control over, so we don't think it's a good use case either. In our case, if there is no start URL, we do assume the top level "/" of the site to which the manifest is served from. I think that is aligned unless I'm missing something. |
Sorry, but that's not what we're proposing here. This proposal makes the default start URL the directory containing the manifest. So if a site has its manifest URL at
So we aren't aligned. Do you think you could change Edge behaviour to pick the directory containing the manifest in the future? Or should we change the proposal here? Note that there was a discussion about "." vs "/" above. I gave some arguments for why we prefer "." in this comment, summarized as "URLs on the Web are always relative by default", so I would prefer ".", but if we have to change to "/" for compat with Edge, we can do so. Please let me know what you'd like to do. |
481f44b
to
2f2b68e
Compare
2f2b68e
to
f2007cc
Compare
@boyofgreen can you follow up on Matt's post here? Otherwise I'd like to propose landing this change. |
@mgiuca This is getting stale. Do you think we can land it soon? |
<li>If <var>start URL</var> is not <a>same origin</a> as | ||
<var>document URL</var>: | ||
<li>If <var>document URL</var> is given, and <var>start URL</var> is | ||
not <a>same origin</a> as <var>document URL</var>: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the document URL is not given, and the start_url has a different origin from the manfiest_url, should we require/recommend the parser of the manifest to verify that the start_url's origin acknowledge this manifest_url?
Sorry @aarongustafson ; this has really slipped off my radar, to the point that I just don't have context on it (I'm not working anywhere near this area). I've essentially handed off the responsibility for this to @philloooo and @dmurph so I think they can take it and land it. Apologies for the churn / confusion. |
Ok, conflict we have here now is that both Safari and Firefox derive the start URL from document URL. I'm inclined to keep with the status quo. Did Chrome ever ship this? |
Like my previous comment said, I haven't been keeping up with this space and @philloooo and @dmurph should weigh in on it.
And Chrome. This change is not about changing Safari and Firefox to be aligned with Chrome. This is about changing Safari, Firefox and Chrome to have reliable behaviour. From memory, the problem is that document URL isn't stable. It means that if you have a manifest without an explicit My argument is that if the spec (basically) says "if |
No problem. I'm happy to work with @philloooo and @dmurph on it... just following up on the
At this point, I'm mostly just specifying what's shipping. It's not ideal, but I'm not optimistic about changes to engines.
Correct.
That's mostly true, but if the site owner wants start_url stability they can add the explicit start_url - or just add |
If |
Breaking: Changed the default start_url to the parent path of the manifest.
Previously, it defaulted to the document URL, which was not stable (the same manifest produces different results in different contexts) and is not guaranteed to exist.
This also makes the document URL optional for the "processing the manifest" algorithm, since it is now only used to check that the document and start_url are same origin.
Preview | Diff