jjb
It's not. window.frames === window evaluates to true. That should
explain things.
/ Jonas
jjb
> / Jonas
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
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
> 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.
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
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
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
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
I suspect it's closer to 16 years than 10.... ;)
-Boris
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
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
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/
> 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
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.