Re: [presentation-api] Partially addresses Issue 275

Thanks @mfoltzgoogle. See additional comment on the note. The pull 
request looks good to me otherwise.

Not directly related to this pull request, but re-reading the 
algorithm, I think it does not really achieve what we'd like it to do.
 My understanding is that we'd like the user agent to create or use 
dedicated storages in the 1UA case. However:

1. The notion of *dedicated storages* (per browsing context) or even 
the notion of *storage* per se may not exist in the specs that are 
referenced. More precisely:
 1. There is only one cookie store per user agent in the cookies RFC, 
not one per browsing context. "Set the cookie store for C to an empty 
cookie store" does not mean much and implies emptying the cookie store
 of the controlling side as well in the 1UA case.
 2. IndexedDB databases are per origin, not per browsing context. "Set
 the IndexedDB databases for C to an empty set of databases" does not 
mean much and could be interpreted as requiring user agents to drop 
the contents of IndexedDB databases for all future connections, even 
those coming from regular (non receiving) browsing contexts. There is 
no notion of a storage that contains all IndexedDB databases in the 
IndexedDB spec.
 3. Unless I missed something, the HTML spec implicitly assumes that 
there is but one storage place for application caches. It does not 
explicitly define a term for that storage.
 4. Same thing for HTTP authentication state, where our goal is only 
to reset data for this browsing context, not for all browsing 
contexts.

2. Some properties are set by relevant algorithms during navigation, 
e.g. when the Document is created. Setting them to some empty storage 
beforehand won't do much, unless we also explicitly say that 
navigation should not affect these properties. Typically:
 1. sessionStorage and localStorage are set when the Document is 
created, which happens during navigation, c.f. two paragraphs below: 
http://www.w3.org/TR/webstorage/#dom-sessionstorage
 2. the application cache is selected during navigation or when the 
HTML document is parsed, c.f. one line below: 
http://www.w3.org/TR/html5/browsers.html#cache-host

Perhaps we can assume that the notion of storage is straightforward to
 grasp and tell the user agent to create new empty storages for the 
receiving browsing context in all cases, as in:

```
<ol>
  <li>Create a new <a>top-level browsing context</a> <var>C</var>,
  set to display content on <var>D</var>.</li>
  <li>Set the <a>session history</a> of <var>C</var> to be the empty
  list.</li>
  <li>Set the <a>sandboxed auxiliary navigation browsing context
  flag</a> on <var>C</var>.</li>
  <li>Create a new empty <a>cookie store</a> for <var>C</var>.</li>
  <li>Create a new empty store for <var>C</var> to hold
  <a>HTTP authentication</a> states.</li>
  <li>Create a new empty <a>application cache</a> storage for 
<var>C</var>.</li>
  <li>If the <a>receiving user agent</a> implements [[!PERMISSIONS]],
  set the <a>permission state</a> of all <a>Permissions</a> for <var>
    C</var> to <code>"denied"</code>.</li>
  <li>If the <a>receiving user agent</a> implements [[!INDEXEDDB]],
  create a new empty storage for IndexedDB <a>databases</a> for 
<var>C</var>.</li>
  <li>If the <a>receiving user agent</a> implements [[!WEBSTORAGE]],
  create a new empty storage for session storage areas and local 
storage
  areas for <var>C</var>.</li>
  <li><a>Navigate</a> <var>C</var> to <var>presentationUrl</var>.</li>
  <li>Start <a>monitoring incoming presentation connections</a> for
  <var>C</var> with <var>presentationId</var>.</li>
</ol>
```

I don't find that entirely satisfactory though. Any better idea?



-- 
GitHub Notification of comment by tidoust
Please view or discuss this issue at 
https://github.com/w3c/presentation-api/pull/308#issuecomment-222954662
 using your GitHub account

Received on Wednesday, 1 June 2016 10:32:08 UTC