Bug 226692

Summary: Reduce use of legacy EventLoopEventQueue and EventLoopTaskQueue
Product: WebKit Reporter: Chris Dumez <cdumez>
Component: MediaAssignee: Chris Dumez <cdumez>
Status: RESOLVED FIXED    
Severity: Normal CC: calvaris, changseok, darin, eric.carlson, esprehn+autocc, ews-watchlist, galpeter, ggaren, glenn, gyuyoung.kim, jer.noble, kangil.han, peng.liu6, philipj, rniwa, sam, sergio, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=226699
Attachments:
Description Flags
Patch
ews-feeder: commit-queue-
Patch
none
Patch
ews-feeder: commit-queue-
Patch
none
Patch ews-feeder: commit-queue-

Chris Dumez
Reported 2021-06-05 19:39:04 PDT
Reduce use of legacy EventLoopEventQueue and EventLoopTaskQueue, and use the HTML event loop directly instead.
Attachments
Patch (45.36 KB, patch)
2021-06-05 19:45 PDT, Chris Dumez
ews-feeder: commit-queue-
Patch (43.44 KB, patch)
2021-06-05 19:49 PDT, Chris Dumez
no flags
Patch (43.62 KB, patch)
2021-06-05 20:59 PDT, Chris Dumez
ews-feeder: commit-queue-
Patch (43.62 KB, patch)
2021-06-05 21:19 PDT, Chris Dumez
no flags
Patch (43.63 KB, patch)
2021-06-06 11:12 PDT, Chris Dumez
ews-feeder: commit-queue-
Chris Dumez
Comment 1 2021-06-05 19:45:04 PDT
Chris Dumez
Comment 2 2021-06-05 19:49:36 PDT
Chris Dumez
Comment 3 2021-06-05 20:59:00 PDT
Chris Dumez
Comment 4 2021-06-05 21:19:09 PDT
Darin Adler
Comment 5 2021-06-05 22:30:29 PDT
Comment on attachment 430674 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=430674&action=review > Source/WebCore/Modules/remoteplayback/RemotePlayback.cpp:293 > + queueTaskToDispatchEvent(*this, TaskSource::MediaElement, event.releaseNonNull()); The old code would silently do nothing if m_state had a bad value. I think this one will crash. Not that a bad value is really possible, but it is a change in behavior. Also, if we are going to refactor to share more code like this, why not have the switch statement just put the event name into an AtomString or const AtomString*, and share the call to Event::create too? > Source/WebCore/dom/FullscreenManager.cpp:68 > + weakThis->dispatchFullscreenChangeEvents(); I’d think that generally we’d want to do something more like: makeRef(*weakThis)->dispatchFullscreenChangeEvents(); I will guess that there is no practical real issue in this case, but our object lifetime strategy is normally to say the caller should be holding a reference to objects before calling functions on them. I’d like these rules to be easier to understand and less situational, but this is what I’ve gleaned from talking to others about our lifetime strategy.
Chris Dumez
Comment 6 2021-06-05 22:43:56 PDT
Comment on attachment 430674 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=430674&action=review >> Source/WebCore/Modules/remoteplayback/RemotePlayback.cpp:293 >> + queueTaskToDispatchEvent(*this, TaskSource::MediaElement, event.releaseNonNull()); > > The old code would silently do nothing if m_state had a bad value. I think this one will crash. Not that a bad value is really possible, but it is a change in behavior. > > Also, if we are going to refactor to share more code like this, why not have the switch statement just put the event name into an AtomString or const AtomString*, and share the call to Event::create too? I did not really see the harm since the switch case was handling all enum values. That said, I like your suggestion of extracting the event from the switch better. I’ll do that before landing. >> Source/WebCore/dom/FullscreenManager.cpp:68 >> + weakThis->dispatchFullscreenChangeEvents(); > > I’d think that generally we’d want to do something more like: > > makeRef(*weakThis)->dispatchFullscreenChangeEvents(); > > I will guess that there is no practical real issue in this case, but our object lifetime strategy is normally to say the caller should be holding a reference to objects before calling functions on them. I’d like these rules to be easier to understand and less situational, but this is what I’ve gleaned from talking to others about our lifetime strategy. Not a new issue as the previous code was not protecting this either, but I will make the change since it is safer.
Chris Dumez
Comment 7 2021-06-06 11:04:58 PDT
(In reply to Chris Dumez from comment #6) > Comment on attachment 430674 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=430674&action=review > > >> Source/WebCore/Modules/remoteplayback/RemotePlayback.cpp:293 > >> + queueTaskToDispatchEvent(*this, TaskSource::MediaElement, event.releaseNonNull()); > > > > The old code would silently do nothing if m_state had a bad value. I think this one will crash. Not that a bad value is really possible, but it is a change in behavior. > > > > Also, if we are going to refactor to share more code like this, why not have the switch statement just put the event name into an AtomString or const AtomString*, and share the call to Event::create too? > > I did not really see the harm since the switch case was handling all enum > values. That said, I like your suggestion of extracting the event from the > switch better. I’ll do that before landing. > > >> Source/WebCore/dom/FullscreenManager.cpp:68 > >> + weakThis->dispatchFullscreenChangeEvents(); > > > > I’d think that generally we’d want to do something more like: > > > > makeRef(*weakThis)->dispatchFullscreenChangeEvents(); > > > > I will guess that there is no practical real issue in this case, but our object lifetime strategy is normally to say the caller should be holding a reference to objects before calling functions on them. I’d like these rules to be easier to understand and less situational, but this is what I’ve gleaned from talking to others about our lifetime strategy. > > Not a new issue as the previous code was not protecting this either, but I > will make the change since it is safer. Same issue as with the last patch you suggested this. FullscreenManager is not RefCounted.
Chris Dumez
Comment 8 2021-06-06 11:12:29 PDT
Ryosuke Niwa
Comment 9 2021-06-06 12:02:45 PDT
(In reply to Chris Dumez from comment #7) > (In reply to Chris Dumez from comment #6) > > Comment on attachment 430674 [details] > > Patch > > >> Source/WebCore/dom/FullscreenManager.cpp:68 > > >> + weakThis->dispatchFullscreenChangeEvents(); > > > > > > I’d think that generally we’d want to do something more like: > > > > > > makeRef(*weakThis)->dispatchFullscreenChangeEvents(); > > > > > > I will guess that there is no practical real issue in this case, but our object lifetime strategy is normally to say the caller should be holding a reference to objects before calling functions on them. I’d like these rules to be easier to understand and less situational, but this is what I’ve gleaned from talking to others about our lifetime strategy. > > > > Not a new issue as the previous code was not protecting this either, but I > > will make the change since it is safer. > > Same issue as with the last patch you suggested this. FullscreenManager is > not RefCounted. We should CheckedPtr in these instances.
EWS
Comment 10 2021-06-06 12:13:15 PDT
Committed r278538 (238536@main): <https://commits.webkit.org/238536@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 430687 [details].
Radar WebKit Bug Importer
Comment 11 2021-06-06 12:14:16 PDT
Note You need to log in before you can comment on or make changes to this bug.