Skip to content

Specify how navigation works... #142

marcoscaceres opened this Issue Feb 11, 2014 · 7 comments

2 participants

World Wide Web Consortium member

Elsewhere, @sicking wrote...

[navigation] likely needs to be more complex than simply
"open off-origin in browser". A common use-case is websites that want
to redirect to facebook-login in order to handle logins.

I think the 80% use-case could be solved by allowing the manifest to
contain a list of URL-patterns which are considered "in app". Anything
else opens in the normal browser. I.e. a whitelist of URL-patterns
that should remain in the existing view.

The trickiest part spec-wise is to figure out what these url-patterns
would look like.

I have heard concerns that some websites are spread out over multiple
domains and aren't sure they can produce a list of patterns that
indicate what's "in app". But I think this is a less common scenario
so definitely something to punt on.

And either way we should make links targetted at "_blank" open in a browser.

And the yet more complicated question is how to handle other opened
windows. I.e. windows opened using or targetted at random
names. Also most likely too complex for v1.

@marcoscaceres marcoscaceres added this to the Future version milestone Feb 11, 2014
World Wide Web Consortium member

Closing for now. Will come back to this in the future.

World Wide Web Consortium member

Related to #93

@marcoscaceres marcoscaceres modified the milestone: Future version Feb 12, 2014
@marcoscaceres marcoscaceres reopened this Feb 25, 2014
@marcoscaceres marcoscaceres added the V2 label Mar 11, 2014
anssiko commented Apr 8, 2014

On a related note, Chrome Extensions Manifest allows whitelisting URLs (the proposed v3 syntax [1] below) using a pattern [2]:

“hosts”: [“*://**”]

URLs matching the pattern can be interacted with in a cross-origin manner using XHR (as well as some other Chrome-specific APIs it seems). For example, given the above, a cross-origin XHR to is allowed without a CORS preflight [3].

I've understood Firefox OS has the "systemXHR" permission flag [4] for the similar purpose, but it's a flag and not a pattern, and is restricted to "privileged" apps only.

That said, I assume being able to do cross-origin XHR does not satisfy the @sicking's requirements for the use case "redirect to facebook-login in order to handle logins". So what is proposed here is we add a manifest member that defines the URL scope similarly for URLs that should remain in the existing view (aka display mode) when navigated to, correct?

Or is it proposed we should bundle both allow navigation and cross-origin XHR et al. under the same setting?

If we go this route in general, I'd like to see whether we can reuse what we have in standards already for pattern matching. Does for example the URL and path matching defined in the CSP spec [5] provide enough granularity to address the use case?


World Wide Web Consortium member

I'm all for using the syntax, but not for anything that violates the web security model. Certainly don't want any system XHR nonsense. The use case for this feature is just to define the boundaries of navigation within the app: basically so ads from other domains don't open in the app. The Facebook case is better handled by

anssiko commented Apr 8, 2014

Agreed about adhering to the Web security model. Anything that says "privileged" is out of scope. To figure out the syntax, we need to understand the use cases.

Pulling together different facets of the issue below.

Specify how navigation works (this issue): #142
URL Scope to which the manifest applies: #114
Sharing scope with manifests: slightlyoff/ServiceWorker#137

World Wide Web Consortium member

We need a standardized URL + wildcard processing algorithm... maybe it already exists? CSP maybe? I think service workers also needs this.

World Wide Web Consortium member

Duplicate of #114

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.