Re: Why can't we just use constructor instead of createdCallback?

2014-01-10 Thread Ryosuke Niwa
On Jan 10, 2014, at 8:16 AM, Boris Zbarsky wrote: > On 1/10/14 11:10 AM, Erik Arvidsson wrote: >> My hope was that it would be rare to override Symbol.create for Elements >> so in most cases we would not need to call user code. > > For spec purposes and parser implementation design purposes tha

[Bug 23487] Actually define going fullscreen

2014-01-10 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23487 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 24232] The containing block of fixpos elements in the top layer shouldn't be the ICB

2014-01-10 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24232 Anne changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: Why can't we just use constructor instead of createdCallback?

2014-01-10 Thread Boris Zbarsky
On 1/10/14 11:10 AM, Erik Arvidsson wrote: My hope was that it would be rare to override Symbol.create for Elements so in most cases we would not need to call user code. For spec purposes and parser implementation design purposes that doesn't matter. If user code can be called, the algorithms

Re: Why can't we just use constructor instead of createdCallback?

2014-01-10 Thread Erik Arvidsson
On Thu, Jan 9, 2014 at 10:57 PM, Ryosuke Niwa wrote: > > 1. The parser does not know that it needs to use MyElement.@@create to > create the JS objects when it sees a . > > On the other hand, solving this seems to require running some author > scripts at the element creation time, at some later t

Re: [HTML imports]: Imports and Content Security Policy

2014-01-10 Thread Frederik Braun
On 10.01.2014 14:51, Nick Krempel wrote: > To clarify: your example is supposed to be an attack on imported.com > , not example.com (we can > assume the attacker has control over example.com )? > > Nick > > ​ Yes, imagine an XSS vulner

Re: [HTML imports]: Imports and Content Security Policy

2014-01-10 Thread Nick Krempel
On 10 January 2014 14:08, Frederik Braun wrote: > Yes, imagine an XSS vulnerability on example.com. Using this to include > imported.com shouldn't mean that the CSP in place (which allows > imported.com) is suddenly allowing everything that is also mentioned in > the policy of imported.com. > Sor

Re: [HTML imports]: Imports and Content Security Policy

2014-01-10 Thread Nick Krempel
To clarify: your example is supposed to be an attack on imported.com, not example.com (we can assume the attacker has control over example.com)? Nick ​

Re: [HTML imports]: Imports and Content Security Policy

2014-01-10 Thread Hajime Morrita
On Fri, Jan 10, 2014 at 5:30 PM, Frederik Braun wrote: > On 10.01.2014 03:52, Hajime Morrita wrote: > > Hi Frederik, > > Thanks for bringing it up! > > > > As you pointed out, CSP of imported documents essentially extends the > > set of allowed domains. I thought I was useful for component author

[Bug 24268] New: [imports]: imported documents should obey CSP on master document.

2014-01-10 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24268 Bug ID: 24268 Summary: [imports]: imported documents should obey CSP on master document. Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux

Re: [HTML imports]: Imports and Content Security Policy

2014-01-10 Thread Frederik Braun
On 10.01.2014 03:52, Hajime Morrita wrote: > Hi Frederik, > Thanks for bringing it up! > > As you pointed out, CSP of imported documents essentially extends the > set of allowed domains. I thought I was useful for component authors to > specify their own domains, like one of their own CDN. Well t