Re: [html5] r7128 - [giow] (2) Try to define img synchronous loading. Affected topics: HTML

[Simon Pieters-3]

On Mon, 11 Jun 2012 22:53:30 +0200, <whatwg@...> wrote:

> Author: ianh
> Date: 2012-06-11 13:53:26 -0700 (Mon, 11 Jun 2012)
> New Revision: 7128
>
> Modified:
>    complete.html
>    index
>    source
> Log:
> [giow] (2) Try to define img synchronous loading.
> Affected topics: HTML

> Modified: source
> ===================================================================
> --- source 2012-06-08 21:50:19 UTC (rev 7127)
> +++ source 2012-06-11 20:53:26 UTC (rev 7128)
> @@ -25449,6 +25449,19 @@
>    per CSS inch, and thus if the image data is 300x600, it has an
>    intrinsic dimension of 96 CSS pixels by 192 CSS pixels.</p>
> +  <p>Each <code>Document</code> object must have a <dfn>list of
> +  available images</dfn>. Each image in this list is identified by a
> +  tuple consisting of an <span>absolute URL</span>, a <span>CORS
> +  settings attribute</span> mode, and, if the mode is not <span
> +  title="attr-crossorigin-none">No CORS</span>, an

> ...

> +   <li><p>Let <var title="">key</var> be a tuple consisting of the
> +   resulting <span>absolute URL</span>, the <code>img</code> element's
> +   <code title="attr-crossorigin">crossorigin</code> attribute's mode,
> +   and, if that mode is not <span title="attr-crossorigin-none">No
> +   CORS</span>, the <code>Document</code> object's
> +   <span>origin</span>.</p></li>

The potentially CORS-enabled fetch algorithm ignores the state of the  
crossorigin attribute when the URL is same-origin. Maybe the sync loading  
logic needs to align with that behavior.

--
Simon Pieters
Opera Software

[Boris Zbarsky]

On 6/12/12 4:47 AM, Simon Pieters wrote:
> The potentially CORS-enabled fetch algorithm ignores the state of the
> crossorigin attribute when the URL is same-origin.

Hmm.  On the face of it, this seems like a bug when open redirectors are
involved...  Is this what UAs implement in practice?

-Boris

[Simon Pieters-3]

On Tue, 12 Jun 2012 20:38:08 +0200, Boris Zbarsky <bzbarsky@...> wrote:

> On 6/12/12 4:47 AM, Simon Pieters wrote:
>> The potentially CORS-enabled fetch algorithm ignores the state of the
>> crossorigin attribute when the URL is same-origin.
>
> Hmm.  On the face of it, this seems like a bug when open redirectors are  
> involved...  Is this what UAs implement in practice?

If it redirects, it switches to CORS. However, there are some bugs in the  
spec... I just filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=17478 
now.

http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#cors-enabled-fetch

--
Simon Pieters
Opera Software

[Boris Zbarsky]

On 6/13/12 4:55 AM, Simon Pieters wrote:
> If it redirects, it switches to CORS. However, there are some bugs in
> the spec... I just filed
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17478 now.

Can we push this whole algorithm down into the CORS spec?  It looks like
at this point fetching-resources.html and the XHR spec are both trying
to define the same algorithm (no CORS for same-origin, check origin on
redirect, switch to CORS as needed, etc), and it would be pretty nice if
they ended up actually defining it the same way.  Simplest way to do
that is to define it in the CORS spec and just reference it in the
others, I'd think.

-Boris

[Simon Pieters-3]

On Wed, 13 Jun 2012 18:09:22 +0200, Boris Zbarsky <bzbarsky@...> wrote:

> On 6/13/12 4:55 AM, Simon Pieters wrote:
>> If it redirects, it switches to CORS. However, there are some bugs in
>> the spec... I just filed
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17478 now.
>
> Can we push this whole algorithm down into the CORS spec?  It looks like  
> at this point fetching-resources.html and the XHR spec are both trying  
> to define the same algorithm (no CORS for same-origin, check origin on  
> redirect, switch to CORS as needed, etc), and it would be pretty nice if  
> they ended up actually defining it the same way.  Simplest way to do  
> that is to define it in the CORS spec and just reference it in the  
> others, I'd think.

Yeah or maybe even merge this algorithm, the fetch algorithm, and the  
cross-origin request algorithms. Currently it's extremely hard to follow.

--
Simon Pieters
Opera Software

[Ian Hickson]

On Wed, 13 Jun 2012, Simon Pieters wrote:

> On Wed, 13 Jun 2012 18:09:22 +0200, Boris Zbarsky <bzbarsky@...> wrote:
> > On 6/13/12 4:55 AM, Simon Pieters wrote:
> > > If it redirects, it switches to CORS. However, there are some bugs
> > > in the spec... I just filed
> > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=17478 now.
> >
> > Can we push this whole algorithm down into the CORS spec?  It looks
> > like at this point fetching-resources.html and the XHR spec are both
> > trying to define the same algorithm (no CORS for same-origin, check
> > origin on redirect, switch to CORS as needed, etc), and it would be
> > pretty nice if they ended up actually defining it the same way.  
> > Simplest way to do that is to define it in the CORS spec and just
> > reference it in the others, I'd think.
>
> Yeah or maybe even merge this algorithm, the fetch algorithm, and the
> cross-origin request algorithms. Currently it's extremely hard to
> follow.

Anne and I plan to do so at some point but doing so would be a lot of work
and we both have bigger fish to fry right now.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Ian Hickson]

On Tue, 12 Jun 2012, Simon Pieters wrote:
>
> The potentially CORS-enabled fetch algorithm ignores the state of the
> crossorigin attribute when the URL is same-origin. Maybe the sync
> loading logic needs to align with that behavior.

The problem is that it doesn't actually entirely ignore it, in particular
if it's a cross-origin redirect. I guess we could work around that by
detecting the case of the image having been loaded entirely same-origin,
and then sticking into the /list of available images/ three separate
entries, one for each possible mode? But then what do we do if one of the
modes is already present, e.g. because we had done an Anonymous fetch and
it had involved a cross-origin redirect, but later we do a With
Credentials fetch and it doesn't (staying same-origin)?

Keeping it just predicated on the crossorigin mode means that the vast
majority of the time, things work predictably and reliably. And it's easy
to implement, in comparison. The only loss is that we don't get sync
loading in the weird case of someone loading an image with and without
CORS when that image is all same-origin, when we normally could, but how
often is that going to happen and will anyone care?


On Tue, 12 Jun 2012, Boris Zbarsky wrote:
>
> Hmm.  On the face of it, this seems like a bug when open redirectors are
> involved...  Is this what UAs implement in practice?

On Wed, 13 Jun 2012, Simon Pieters wrote:
>
> If it redirects, it switches to CORS. However, there are some bugs in
> the spec... [...]

Fixed.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'