Hi folks.
I recently noticed that far too much of the logic for the DOM window object is
in the JavaScript bindings rather than in the DOM implementation of the window
object itself. I also see efforts to make a “generic” binding that is currently
used mostly for V8 only but seems intended for later use by JSC.
I think we’re going about this the wrong way. The general rule for the DOM is
to do the work in the DOM classes rather than in the binding. The job of the
binding is to extract the arguments and call through to the DOM. This is how we
should be doing it.
Let me give an example. When setting the location attribute of the DOM window,
the binding should extract the active frame and first frame, convert the value
of the attribute to a string, and then call through to the DOMWindow object.
The security logic should be in the DOMWindow.h/cpp file, not in the binding.
I know this is a departure from what was in JSDOMWindowCustom.cpp; but that
historic code is not a good template to base future code on. We should desist
in making a cross-JavaScript-engine binding layer for code that doesn’t belong
in the binding layer at all.
I’m working on a patch for setLocation and then I’ll move on to open and
showModalDialog.
Once we have done enough of this work, we should be able to remove a lot of
unneeded code from files like BindingSecurity.h, BindingSecurityBase.h,
BindingSecurityBase.cpp, BindingLocation.h, BindingFrame.h, BindingDOMWindow.h,
GenericBinding.h, JSDOMWindowBase.h, and JSDOMWindowBase.cpp.
We really don’t want to spread security responsibilities into the bindings.
What the bindings need to do is communicate the scripting context when calling
in the DOM. The DOM can implement security rules and such in a way that’s
independent of the bindings.
Let me know what you think.
-- Darin
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
