window.frames
johnjbarton
Object.keys(window.frames) looks like window. How can I determine that
the window.frames is actually an array of windows?
jjb
Jonas Sicking
It's not. window.frames === window evaluates to true. That should
explain things.
/ Jonas
johnjbarton
According to
https://developer.mozilla.org/en/DOM/window.frames
Returns an array-like object, listing the direct sub-frames of the
current window.
Is that page wrong?
jjb
> / Jonas
Boris Zbarsky
> ? Ok why is window.frames === window?
Because that's how it was implemented back in the early 90s in Netscape,
and the web depends on that behavior.
In particular, window.frames[5] === window[5], for obvious reasons.
> According to
> https://developer.mozilla.org/en/DOM/window.frames
> Returns an array-like object, listing the direct sub-frames of the
> current window.
> Is that page wrong?
Yep. window.frames returns the window itself. It's just that most
developers don't realize that Window is an array-like object
(window.length is the number of subframes, etc).
-Boris
johnjbarton
> On 6/12/11 12:05 PM, johnjbarton wrote:
>> ? Ok why is window.frames === window?
>
> Because that's how it was implemented back in the early 90s in Netscape,
> and the web depends on that behavior.
>
> In particular, window.frames[5] === window[5], for obvious reasons.
Why is this obvious?
Is there any other API that returns the frames, in a sane manner?
>
>> According to
>> https://developer.mozilla.org/en/DOM/window.frames
>> Returns an array-like object, listing the direct sub-frames of the
>> current window.
>> Is that page wrong?
>
> Yep. window.frames returns the window itself. It's just that most
> developers don't realize that Window is an array-like object
> (window.length is the number of subframes, etc).
Most? I bet that is a wild underestimate ;-).
jjb
>
> -Boris
Neil
> On 6/12/2011 2:09 PM, Boris Zbarsky wrote:
>
>> On 6/12/11 12:05 PM, johnjbarton wrote:
>>
>>> ? Ok why is window.frames === window?
>>
>> Because that's how it was implemented back in the early 90s in
>> Netscape, and the web depends on that behavior.
>>
>> In particular, window.frames[5] === window[5], for obvious reasons.
>
> Why is this obvious?
Well, there's
http://mxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#5797
> Is there any other API that returns the frames, in a sane manner?
Not exactly sane, but
http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsIDOMWindow.idl#88
(the declaration of the GetFrames referenced above lives in nsIDOMJSWindow)
--
Warning: May contain traces of nuts.
Boris Zbarsky
>> In particular, window.frames[5] === window[5], for obvious reasons.
>
> Why is this obvious?
Because window.frames === window and window[5] === window[5].
> Is there any other API that returns the frames, in a sane manner?
There is not, to my knowledge. In particular, this is the only API that
returns windows for subdocuments loaded via <object> in Gecko and
WebKit. If you ignore those you could do this:
Array.slice(document.querySelectorAll("iframe,frame")).
map(function(f) { return f.contentWindow; });
(or variations not using Array generics if you need this to work in
non-Spidermonkey JS engines and such).
Then again, what qualifies as "sane"?
-Boris
johnjbarton
An array of subframes is a fine API. It's small and would make sense for
the purpose.
window.length/window[] as API is lame, but it feels old and thus
generates some sympathy.
window.frames returning window is the opposite of "least astonishment",
totally confusing and pointless.
JavaScript program understanding tools should rely first on 'shape', the
properties of an object. Bizarre properties like 'frames' cannot be
analyzed by shape. Instead we have to add special case code for
window.frames. But wait we can't: because window.frames returns window,
that is all we can show the user.
jjb
Jonas Sicking
No one is claiming to like the API. The only reason it looks like it
does is because the web depends on it at this point. Why it happened
in the first place I can only guess, but likely due to an accidental
decision of bug 10 years ago or so.
But yes, I absolutely think we should be up front about the fact that
window.frames === window. Both in MDC and in developer tools.
/ Jonas
Boris Zbarsky
> window.frames returning window is the opposite of "least astonishment",
> totally confusing and pointless.
Hey, no argument there.
That said, I thought your insanity worry was about the fact that
window[n] may or may not be a frame depending on what other properties
have been defined on the window.....
-Boris
Boris Zbarsky
> but likely due to an accidental decision of bug 10 years ago or so.
I suspect it's closer to 16 years than 10.... ;)
-Boris
johnjbarton
Something like window.frameList could be added and it could be sane.
That is what I was hoping to hear from Boris.
>
> But yes, I absolutely think we should be up front about the fact that
> window.frames === window. Both in MDC
Tried, my save failed.
> and in developer tools.
That's already true for Firebug. I was trying to fix it to match the MDC
page. But I could not make sense of the results I was getting so I
started this thread. Now it's "fixed" by doing nothing.
jjb
>
> / Jonas
David Dahl
In a nutshell, the DOMCrypt API is an API for the browser that would be integrated into window.crypto and allow content developers to easily, quickly and safely perform public key and symmetric crypto as well as hash and hmac.
A pretty good summary is in my latest blog post, which points to all of the relevant links: http://monocleglobe.wordpress.com/2011/06/13/domcrypt-round-up/
Bugs:
Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=649154
WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=62010
Cheers,
David
L. David Baron
> In trying to get the word out about a browser crypto API I am
> championing (see:
> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
> ), I wanted to post here for feedback and criticism.
Hmm, I may as well respond here, though I'm a little concerned about
how many places the feedback on this is going.
I'm a little confused by the |algorithm| attributes that appear in a
bunch of places (and are mentioned in your blog); having per-window
attributes like that seems a little risky, e.g., if two scripts are
encrypting different pieces of data and competing with each other.
(Also, what happens if one script wants the default, but it's been
changed by some other script to, say, an old not-as-good algorithm?
Is there a way to get back to the default?) And is there a list of
the allowed values of the attribute somewhere?
-David
> A pretty good summary is in my latest blog post, which points to all of the relevant links: http://monocleglobe.wordpress.com/2011/06/13/domcrypt-round-up/
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
David Dahl
> From: "L. David Baron" <dba...@dbaron.org>
> To: "David Dahl" <dd...@mozilla.com>
> Cc: dev-pl...@lists.mozilla.org
> Sent: Monday, June 13, 2011 5:50:36 PM
> Subject: Re: DOMCrypt API developments
> On Monday 2011-06-13 15:31 -0700, David Dahl wrote:
> > In trying to get the word out about a browser crypto API I am
> > championing (see:
> > https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
> > ), I wanted to post here for feedback and criticism.
>
> Hmm, I may as well respond here, though I'm a little concerned about
> how many places the feedback on this is going.
>
> I'm a little confused by the |algorithm| attributes that appear in a
> bunch of places (and are mentioned in your blog); having per-window
> attributes like that seems a little risky, e.g., if two scripts are
> encrypting different pieces of data and competing with each other.
> (Also, what happens if one script wants the default, but it's been
> changed by some other script to, say, an old not-as-good algorithm?
> Is there a way to get back to the default?) And is there a list of
> the allowed values of the attribute somewhere?
>
Currently there is only one value allowed (for crypto ops), AES_256_CBC, and has not been added to the spec. That is on my to do list. As far as scripts changing the value, that is a valid concern which I have not thought much about. I'm thinking that the objects produced by all operations should have an algorithm property as well, so we can exit if there is a mismatch.
Regards,
David
Jean-Marc Desperrier
>>> In trying to get the word out about a browser crypto API I am
>>> championing (see:
>>> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>>> ), I wanted to post here for feedback and criticism.
>>
>> Hmm, I may as well respond here, though I'm a little concerned about
>> how many places the feedback on this is going.
>>
> I am trying to communicate this to as many interested parties as
> possible. I also don't want to force anyone to join another list to
> offer feedback. I am not planning to post this to any further mailing
> lists.
However you did not post this to the obvious choice of
mozilla.dev.tech.crypto.
I find this API effort very interesting, however I'm left with the
feeling you wish to leave out the use of PKI elements.
A really neutral API would work both with and without PKI.
