Generate and use cross frame wrappers for types in other frames/windows.

Generate and use cross frame wrappers for types in other frames/windows.

This gets the two blocking tests working plus a bonus one.

Note, this does not yet include:
- Wrapping html_dartium
- Wrapping parameters (Window is passed into some init*Event methods and Location is passed into the setter on Window)
- Generating error stubs that throw on illegal methods.

I also haven't generated wrappers for dart:dom.  Not sure this is worth it.

BUG=http://code.google.com/p/dart/issues/detail?id=2774
TEST=html/cross_frame_test,html/inner_frame_test,html/window_open_test

[sra1, 2012-05-10 00:12:05]

I will review the minimal fix this evening.

https://chromiumcodereview.appspot.com/10378040/diff/3001/lib/dom/scripts/sys...
File lib/dom/scripts/systemhtml.py (right):

https://chromiumcodereview.appspot.com/10378040/diff/3001/lib/dom/scripts/sys...
lib/dom/scripts/systemhtml.py:443: # only defined under #define V8_BINDING.
What are the tuple elements?

https://chromiumcodereview.appspot.com/10378040/diff/3001/lib/dom/scripts/sys...
lib/dom/scripts/systemhtml.py:450: _wrapped_types =
_cross_frame_wrapped_types.keys()
Comment that this list may be extended to non-cross-frame-wrapped-types.  (I
assume that is why this is separate)

https://chromiumcodereview.appspot.com/10378040/diff/3001/lib/dom/scripts/sys...
lib/dom/scripts/systemhtml.py:452: def _WrapAndReturnObject(container_interface,
return_interface, expr, getter):
Just make this wrap the expression.
_WrapIfCrossFrame(...)

https://chromiumcodereview.appspot.com/10378040/diff/3001/lib/dom/scripts/sys...
lib/dom/scripts/systemhtml.py:453: if return_interface in
_cross_frame_wrapped_types.keys():
You can use 'in' on dictionaries directly.

https://chromiumcodereview.appspot.com/10378040/diff/3001/lib/dom/scripts/sys...
lib/dom/scripts/systemhtml.py:645: class HtmlCrossFrameSystem(HtmlSystem):
I have been ordering them:  System1 InterfaceGenerator1 System2
InterfaceGenerator2 ...
So move this down to ~1800.
I have also been putting # ---- between the classes since they span several
pages it is too easy to end up in the wrong one.

https://chromiumcodereview.appspot.com/10378040/diff/3001/lib/dom/scripts/sys...
lib/dom/scripts/systemhtml.py:779: if 'CheckSecurityForNode' in (getter or
setter).ext_attrs:
Comment on why.

https://chromiumcodereview.appspot.com/10378040/diff/3001/lib/dom/scripts/sys...
lib/dom/scripts/systemhtml.py:1098: '\n  $TYPE get $(HTML_NAME)() {'
Any reason not to use => syntax?

https://chromiumcodereview.appspot.com/10378040/diff/3001/lib/dom/scripts/sys...
lib/dom/scripts/systemhtml.py:1124: # Do we need a native body?
"Do we need a wrapper or a native body?"

https://chromiumcodereview.appspot.com/10378040/diff/3001/lib/dom/scripts/sys...
lib/dom/scripts/systemhtml.py:1140: operation_emitter.Emit(
Could fold this into the previous one.

https://chromiumcodereview.appspot.com/10378040/diff/3001/lib/dom/scripts/sys...
lib/dom/scripts/systemhtml.py:1962: def GenerateSingleOperation(self,  emitter,
info, indent, operation):
We really need to avoid another copy of the dispatch generator.  Anton is
already trying to refactor it in a separate CL.
(https://chromiumcodereview.appspot.com/10375026/)

Perhaps we should go with the minimal fix and get the refactoring done right.

As I mentioned in the html_frog file, there is something wrong with the argument
expressions.

https://chromiumcodereview.appspot.com/10378040/diff/3001/lib/html/frog/html_...
File lib/html/frog/html_frog.dart (right):

https://chromiumcodereview.appspot.com/10378040/diff/3001/lib/html/frog/html_...
lib/html/frog/html_frog.dart:127: +      _ptr.postMessage(message, targetOrigin,
messagePorts);
Why are the branches the same?
The main point of generating a dispatch is to preserve the number of arguments
passed to the lower layer.
(Another reason would be to unwrap arguments in a type dependent manner).

https://chromiumcodereview.appspot.com/10378040/diff/3001/tests/html/inner_fr...
File tests/html/inner_frame_test.dart (right):

https://chromiumcodereview.appspot.com/10378040/diff/3001/tests/html/inner_fr...
tests/html/inner_frame_test.dart:21: // TODO(vsm): This should be
UnsupportedOperationException.
Do you think it is worth catching both exceptions?

[podivilov, 2012-05-30 13:18:44]

Vijay,

What if we introduce three custom handwritten interfaces CrossFrameWindow (11
methods), CrossFrameLocation (1 method), CrossFrameHistory (3 methods) and will
use them everywhere as parameters and return values except for a few cases:
1) Window get window()
2) History Window.history
3) Location Window.location 
Unsafe interfaces should still be auto-generated, but should extend
corresponding cross-frame interfaces.

That would give us more relevant suggestions for iframe.contentWindow.* and 
iframe.contentWindow.location.*.
And it's probably easier to add ~100 lines of custom dart code than ~300 lines
of python in systemhtml.

What do you think?