Re: Mutation events replacement

On Wed, Jul 6, 2011 at 2:47 AM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:

> On 07/06/2011 08:14 AM, James Robinson wrote:
>
>> On Tue, Jul 5, 2011 at 5:51 PM, Ojan Vafai <ojan@chromium.org
>> <mailto:ojan@chromium.org>> wrote:
>>
>>    On Tue, Jul 5, 2011 at 5:36 PM, Ryosuke Niwa <rniwa@webkit.org
>>    <mailto:rniwa@webkit.org>> wrote:
>>
>>        On Tue, Jul 5, 2011 at 5:27 PM, Rafael Weinstein
>>        <rafaelw@google.com <mailto:rafaelw@google.com>> wrote:
>>
>>            It seems like these are rarified enough cases that visual
>>            artifacts
>>            are acceptable collateral damage if you do this. [Put
>>            another way, if
>>            you care enough about the visual polish of your app that you
>>            will put
>>            energy into avoiding flickr, you probably aren't using alert
>> and
>>            showModalDialog anyway].
>>
>>            Also, it's up to the app when to do it, so it's entirely in its
>>            control (and thus avoid visual artifacts).
>>
>>
>>        Given that we don't provide an API to control paint in general,
>>        I'm not convinced that we should add such a requirement in the
>>        DOM mutation event spec.
>>
>>
>>    Many of the use-cases for mutation events (e.g. model-driven views)
>>    are poorly met if we don't give some assurances here.
>>
>>            Note that this is a problem with both proposals. Work done
>>            in (at
>>            least some) mutation observers is delayed. If a sync paint
>>            occurs
>>            before it, it's work won't be reflected on the screen.
>>
>>
>>        Right.  Maybe we can add a note saying that the user agents are
>>        recommended not to paint before all mutation observers are
>>        called.  I don't think we should make this a requirement.
>>
>>
>>    There may be a middle ground that isn't so hard to for browser
>>    vendors implement interoperably. Can we require no repaint except in
>>    the presence of a specific list synchronous API calls? I'm sure
>>    that's too simplistic, but I'm hoping someone with more experience
>>    can chime in with something that might actually be a plausible
>>    requirement.
>>
>>
>> HTML specifies to a limited extent when painting can happen with regard
>> to what it defines as tasks:
>>
>> http://www.whatwg.org/specs/**web-apps/current-work/**
>> multipage/webappapis.html#**processing-model-2<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#processing-model-2>
>>
>> See step 5 - "update the rendering" is equivalent to painting.  Ignoring
>> step (2) which relates to the storage mutex, this description is
>> accurate.  No browser updates the rendering after invoking every single
>> task, but I'm pretty sure that no modern browser updates the rendering
>> at any other time.  Note that a few APIs such as showModalDialog()
>> invoke this algorithm:
>>
>> http://www.whatwg.org/specs/**web-apps/current-work/**
>> multipage/webappapis.html#**spin-the-event-loop<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#spin-the-event-loop>
>>
>> which effectively starts up a second event loop within the processing of
>> a task, meaning that the browser can paint while the task that resulted
>> in the showModalDialog() call is still running.  Authors who are using
>> showModalDialog() are being extremely user-hostile so I don't think we
>> need to accomodate them.
>>
>
>
> Sync XHR is one case when at least some browsers do repainting.
> And yes, sync XHR is probably as user-hostile as showModalDialog(), but
> unfortunately it is used quite often.
>
> What browser(s) do this?  That sounds like a bug in those
implementation(s), and not something we should worry about standards-wise.

- James


>
>
>
>
>> One question I have with regards to the proposed processing model is
>> whether to define this in terms of entering script or in terms of
>> 'tasks' in the HTML sense.  For example, asynchronous DOM events are
>> typically set up by queueing a single task to fire the event, but there
>> might be multiple event listeners registered for that one event that
>> would all be fired as part of the same task.  If we were to define
>> things in terms of tasks, then I think Rafael's proposal is similar to
>> extending step 4 "provide a stable state" of the event loop algorithm in
>> order to notify observers before proceeding to step 5.  This would mean
>> that if multiple click handlers were registered on an element and the
>> user clicked on it, all of the event handlers would run, then the
>> mutation observers would run, then the browser would be free to paint if
>> it chose to.  An alternative approach would be to hook on calling in to
>> script
>> (http://www.whatwg.org/specs/**web-apps/current-work/**
>> multipage/webappapis.html#**calling-scripts<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#calling-scripts>
>> )
>> and run the observers after each script invocation.  This means that if
>> multiple handlers were registered for an event then the first handler
>> would be invoked, then observers notified, then the second handler
>> invoked, etc.  It would still have the property that the observers would
>> always run before the browser painted so long as no script spun the
>> event loop.
>>
>> I hope this helps.  This has been a long thread and I haven't had a
>> chance to fully digest all of it, but I'm really happy that people are
>> taking a serious look at this problem.
>> - James
>>
>>
>>
>>        - Ryosuke
>>
>>
>>
>>
>