Re: why not MediaQueryList.onchange

On 3/31/14 5:25 PM, Jochen Eisinger wrote:
> The other callbacks don't have a property that gets invoked, it's e.g.
> setTimeout(function() { ..}, 42) and not setTimeout({timeout: function()
> { ...}}, 42);

Neither does the spec.  The spec says:

   callback MediaQueryListListener = void (MediaQueryList list);

which has no property being invoked; it's just a straight-up function.

(On a separate note, there are in fact two things in the platform that 
invoke properties like that: event listeners and nodefilters.  But I 
agree those are a lot more rare than callback functions.)

> Well, and WebKit. In both cases, it's a single line of IDL, but the C++
> part that stores the listeners and invokes them is huge.

It is?  Here's the part that stores the callback in Gecko, ignoring an 
issue to do with the lifetime of the list object itself that would not 
change with event listeners:

  void
  MediaQueryList::AddListener(MediaQueryListListener& aListener)
...
    for (uint32_t i = 0; i < mCallbacks.Length(); ++i) {
      if (aListener == *mCallbacks[i]) {
        // Already registered
        return;
      }
    }
    mCallbacks.AppendElement(&aListener);

and two more lines to deal with possible ownership cycles through that 
object.

Invoking the listeners snapshots the list, and then:

           nsAutoMicroTask mt;
           MediaQueryList::HandleChangeData &d = notifyList[i];
           ErrorResult result;
           d.callback->Call(*d.mql, result);


The code for using an EventTarget here would be not much smaller, 
actually, because we'd have to override add/removeEventListeners to do 
some bookkeeping (Gecko doesn't bother live-updating MediaQueryLists no 
one is listening to).

I'm sympathetic to arguments that the current setup in the spec is 
confusing to web developers, but not so much to arguments that it's 
particulary onerous to implement.

-Boris

Received on Monday, 31 March 2014 23:17:01 UTC