Bug 163568 – Changing details.open should cause a toggle event to be fired asynchronously

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Chris Dumez]

Changing details.open should cause a toggle event to be fired asynchronously:
- https://html.spec.whatwg.org/#details-notification-task-steps

Firefox and Chrome implement this, we don't.

[Chris Dumez]

Created attachment 291888 [details]
Patch

[Darin Adler]

Comment on attachment 291888 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=291888&action=review

> Source/WebCore/html/HTMLDetailsElement.cpp:160
> +            // https://html.spec.whatwg.org/#details-notification-task-steps.
> +            detailToggleEventSender().cancelEvent(*this);
> +            detailToggleEventSender().dispatchEventSoon(*this);

A single global event sender? I don’t understand why this is global; seems arbitrary to share with all other code in the same process but not any other code.

[Chris Dumez]

Comment on attachment 291888 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=291888&action=review

>> Source/WebCore/html/HTMLDetailsElement.cpp:160
>> +            detailToggleEventSender().dispatchEventSoon(*this);
> 
> A single global event sender? I don’t understand why this is global; seems arbitrary to share with all other code in the same process but not any other code.

I followed the pattern in HTMLLinkElement and HTMLStyleElement. I think the idea is to avoid having an EventSender<> per element for memory reasons. So at least, all the detail elements on the page share the same queue.

[Darin Adler]

Comment on attachment 291888 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=291888&action=review

>>> Source/WebCore/html/HTMLDetailsElement.cpp:160
>>> +            detailToggleEventSender().dispatchEventSoon(*this);
>> 
>> A single global event sender? I don’t understand why this is global; seems arbitrary to share with all other code in the same process but not any other code.
> 
> I followed the pattern in HTMLLinkElement and HTMLStyleElement. I think the idea is to avoid having an EventSender<> per element for memory reasons. So at least, all the detail elements on the page share the same queue.

I guess it’s OK. I realize now that they all share one big queue but none can tell it’s a shared queue.

[WebKit Commit Bot]

Comment on attachment 291888 [details]
Patch

Rejecting attachment 291888 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-01', 'land-attachment', '--force-clean', '--non-interactive', '--parent-command=commit-queue', 291888, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit

Last 500 characters of output:
0-ab3c-d52691b4dbfc ...
Currently at 207501 = 4a07cf3530bbc1acb6acb53554a88d2f9f11f5a6
r207505 = bcbd4161469e47bfd99535ba58ea524f4b9f6285
r207506 = a10e938093fa5aafe64bb73b291653a78b7ba9c1
r207507 = 06616105323a3ea387cb6a12da0034419539dbb6
r207508 = a1f7e8b8f1451e7cdcae1746c9bf50bc879ad2ea
Done rebuilding .git/svn/refs/remotes/origin/master/.rev_map.268f45cc-cd09-0410-ab3c-d52691b4dbfc
First, rewinding head to replay your work on top of it...
Fast-forwarded master to refs/remotes/origin/master.

Full output: http://webkit-queues.webkit.org/results/2319366

[Chris Dumez]

Committed r207514: <http://trac.webkit.org/changeset/207514>

[Radar WebKit Bug Importer]

<rdar://problem/90690124>