Re: [beacon] Random comments

It was being discussed on this thread. I've copied it below. What do you
suggest?


Simon:
Hmm. HTML APIs mostly use http://www.whatwg.org/specs/web-apps/current-work/
multipage/webappapis.html#incumbent-settings-objectalthough that's
different to XHR. If we want like XHR you can say the context object's
document's global object's settings object (phew), or some such. But I'm
not sure which is better. Anne, Hixie?

Anne:
HTML seems to use a mix of entry settings object and incumbent
settings object, depending on whether it is about resolving URLs or
origin checks. I'm not entirely sure when that difference is
observable. I would recommend against copying logic from
XMLHttpRequest however, as it has some legacy around a strong tie
between the interface object and that object's associated document
which is not needed for new things.

Boris:
HTML actually uses incumbent settings objects in most cases, I believe; the
entry settings cases are the ones imposed by compat constraints.
Say you have a web page like so:
  <iframe src="foo.html"></iframe>
  <script>
    onload = function() {
      frames[0].f();
    }
  </script>

and foo.html has:

  <script>
    function f() {
      // do something
    }
  </script>

then "do something" has the main web page as the entry settings object but
foo.html as the incumbent settings object.  So if "f" did a location set,
for example, the base URI for that string would be the main web page
(because Location uses the entry settings object for the base URI), which
is a bizarre non-local effect that I don't think we should be duplicating
for other APIs...



On Tue, Feb 11, 2014 at 5:41 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 2/11/14 1:00 AM, Arvind Jain wrote:
>
>> Did we reach consensus on what changes we make to the algorithm re.
>> which settings object to use?
>>
>
> Did we discuss it at all?
>
> -Boris
>