In JSDOMWindow::getOwnPropertySlot, we currently look for the property on the JSDOMWindow, then we search the window's subframes for name getters, then we look in the window's prototype chain. Apparently we were doing the lookup in this order to be compatible with Mozilla, but Mozilla does not implement this behavior. Instead, they do the lookup on the prototype before looking for subframe name getters. We should change this to match Mozilla. This has the convenient side effect of allowing us to cache lookups in the window's prototype chain.
Created attachment 231476 [details] Patch
Comment on attachment 231476 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=231476&action=review r=me > Source/WebCore/ChangeLog:15 > + Mozilla no longer implements this behavior. Instead, they do the lookup on the prototype before > + looking for subframe name getters. We should change this to match Mozilla. This has the convenient > + side effect of allowing us to cache lookups in the window's prototype chain. FWIW, I think Mozilla and WebIDL technically specify that name getters should exist in the prototype chain between the window prototype and the object prototype. So, eventually, we'll want to do that, and verify that a frame named "toString" takes precedence over Object.prototype.toString. Still, this patch is a step in the right direction. I don't think I'll let <iframe name="toString"> stand in our way.
Comment on attachment 231476 [details] Patch Clearing flags on attachment: 231476 Committed r168902: <http://trac.webkit.org/changeset/168902>
All reviewed patches have been landed. Closing bug.
(In reply to comment #2) > FWIW, I think Mozilla and WebIDL technically specify that name getters should exist in the prototype chain between the window prototype and the object prototype. So, eventually, we'll want to do that, and verify that a frame named "toString" takes precedence over Object.prototype.toString. > > Still, this patch is a step in the right direction. I don't think I'll let <iframe name="toString"> stand in our way. Sure would be nice having a test demonstrating this problem that remains.