html_tests fail after recent WebKit merge

[rakudrama]

DumpRenderTree is built against WebKit. Sometime before r2857 Dartium changed by picking up two changes.

(1) CSSDeclaration.hasOwnProperty returns 'true' for arbitrary arguments. This breaks the dartc wrapping version of dart:dom. This can be fixed with extra checks - that the hash map is present and a valid object.

(2) Some Events have lost their initXXXEvent methods.

104 ERROR Expectation: Event BeforeLoadEvent. Caught NoSuchMethodException - receiver: '' function name: 'initBeforeLoadEvent' arguments: []]
105 ERROR Expectation: Event CloseEvent. Caught NoSuchMethodException - receiver: '' function name: 'initCloseEvent' arguments: []]
108 ERROR Expectation: Event ErrorEvent. Caught NoSuchMethodException - receiver: '' function name: 'initErrorEvent' arguments: []]
114 ERROR Expectation: Event OverflowEvent. Caught NoSuchMethodException - receiver: '' function name: 'initOverflowEvent' arguments: []]
115 ERROR Expectation: Event PageTransitionEvent. Caught NoSuchMethodException - receiver: '' function name: 'initPageTransitionEvent' arguments: []]
116 ERROR Expectation: Event ProgressEvent. Caught NoSuchMethodException - receiver: '' function name: 'initProgressEvent' arguments: []]
122 ERROR Expectation: Event XMLHttpRequestProgressEvent. Caught NoSuchMethodException - receiver: '' function name: 'initProgressEvent' arguments: []]

In JavaScript, instead of creating an event and then calling the initXXXEvent method, the parameters are passed as a dictionary to the constructor.

Before (JS):
  var c = document.createEvent('CloseEvent');
  c.initCloseEvent('close', false, true, false, 42, 'boogers');

is now in WebKit simply

  new CloseEvent('close', {
      bubbles: false,
      cancelable: true,
      wasClean: false,
      code: 42,
      reason: 'boogers'
    });

What is not clear:

(A) Does the new constructor pattern apply to all events, i.e. including events that still have initXXXEvent methods?
(B) Does the IDL contain enough information to generate the constructor automatically?

We need to design the Dart binding and implement it on both Dartium and JavaScript targets.

The JavaScript target is going to have to support both styles since it will be some time before all browsers are consistent. This will incur some unwelcome overhead.

Passing a dictionary does have some advantages - the code can be table-driven.
I suggest first that we use named parameters in the constructor.
Named parameters will have a superior experience in the editor since they will be available for auto-completion.

It appears that in the future an 'invocation mirror' will allow a map to be passed to a function taking named parameters. If that turns out not to work, we can add a named constructor that takes a map:

interface CloseEvent ... {
  CloseEvent(
      String type,
      [bool bubbles = false,
       bool cancelable = false,
       bool wasClean = false,
       int code = 0,
       String reason = '']);
  CloseEvent.fromMap(String type, Map map); // Optional.
}

This can be called as:

  new CloseEvent('close', cancelable: true, code: 42, reason: 'boogers');

  new CloseEvent.fromMap('close', {
      'bubbles': false,
      'cancelable': true,
      'wasClean': false,
      'code': 42,
      'reason': 'boogers'
    });
               

[DartBot]

This comment was originally written by [email protected]

---

Issue #993 has been merged into this issue.

[vsmenon]

Removed Area-UI label.
Added Area-DOM label.

[DartBot]

This comment was originally written by [email protected]

---

(A) Does the new constructor pattern apply to all events, i.e. including events that still have initXXXEvent methods?

Yes, the new constructor pattern should apply to all events. The up-to-date status is on this bug: <https://bugs.webkit.org/show_bug.cgi?id=67824>

This is the meta-bug for removing the init*Event methods: <https://bugs.webkit.org/show_bug.cgi?id=68791> Not all will be removed for backwards compatibility. However there is no reason to expose them via Dart.

(B) Does the IDL contain enough information to generate the constructor automatically?

I think so: grep WebKit IDLs for the InitializedByEventConstructor attribute. The spec IDLs are nicer because they have a specific argument you can extract the properties of.

We need to design the Dart binding and implement it on both Dartium and JavaScript targets.

The JavaScript target is going to have to support both styles since it will be some time before all browsers are consistent. This will incur some unwelcome overhead.

Can you give more details on where the overhead is?

Passing a dictionary does have some advantages - the code can be table-driven.
I suggest first that we use named parameters in the constructor.
Named parameters will have a superior experience in the editor since they will be available for auto-completion.

This API is always discussed in terms of the init*Event argument lists being too long and cryptic and the argument being an object literal – effectively like named parameters – although it is not a requirement. So I think named parameters make sense.

[vsmenon]

Note, this test has been broken into several. The event constructor issues remain.

---

Set owner to @rakudrama.
Added this to the M1 milestone.

[vsmenon]

Added Fixed label.