Bug 202279 - [iOS] Lock screen controls can fail to play web content
Summary: [iOS] Lock screen controls can fail to play web content
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Jer Noble
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2019-09-26 11:15 PDT by Jer Noble
Modified: 2019-09-27 09:27 PDT (History)
4 users (show)

See Also:


Attachments
Patch (9.56 KB, patch)
2019-09-26 11:23 PDT, Jer Noble
no flags Details | Formatted Diff | Diff
Patch (9.24 KB, patch)
2019-09-26 12:24 PDT, Jer Noble
no flags Details | Formatted Diff | Diff
Patch (9.13 KB, patch)
2019-09-26 12:49 PDT, Jer Noble
no flags Details | Formatted Diff | Diff
Patch (13.20 KB, patch)
2019-09-26 15:01 PDT, Jer Noble
no flags Details | Formatted Diff | Diff
Patch for landing (13.29 KB, patch)
2019-09-26 15:53 PDT, Jer Noble
no flags Details | Formatted Diff | Diff
Patch for landing (13.48 KB, patch)
2019-09-26 16:39 PDT, Jer Noble
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jer Noble 2019-09-26 11:15:21 PDT
[iOS] Lock screen controls can fail to play web content
Comment 1 Jer Noble 2019-09-26 11:22:36 PDT
<rdar://50920870>
Comment 2 Jer Noble 2019-09-26 11:23:24 PDT
Created attachment 379663 [details]
Patch
Comment 3 Chris Dumez 2019-09-26 11:51:02 PDT
Comment on attachment 379663 [details]
Patch

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

> Source/WebKit/Shared/Cocoa/ProcessTaskStateObserver.h:61
> +        virtual void refClient() = 0;

Should these be private?

> Source/WebKit/Shared/Cocoa/ProcessTaskStateObserver.mm:72
> +    return *new ProcessTaskStateObserver(client);

Missing the adoptRef(), so this will leak.

> Source/WebKit/Shared/Cocoa/ProcessTaskStateObserver.mm:95
> +void ProcessTaskStateObserver::invalidate()

Who is calling this? I could not find a caller.

> Source/WebKit/Shared/Cocoa/ProcessTaskStateObserver.mm:104
> +    return makeRefPtr(m_client);

Note that this is not generally thread safe, what guarantees that the destructor of m_client is not currently running on another thread.

> Source/WebKit/WebProcess/WebProcess.h:455
> +    void derefClient() final { ref(); }

should be deref() :(
Comment 4 Jer Noble 2019-09-26 12:11:04 PDT
(In reply to Chris Dumez from comment #3)
> Comment on attachment 379663 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=379663&action=review
> 
> > Source/WebKit/Shared/Cocoa/ProcessTaskStateObserver.h:61
> > +        virtual void refClient() = 0;
> 
> Should these be private?

Sure!

> > Source/WebKit/Shared/Cocoa/ProcessTaskStateObserver.mm:72
> > +    return *new ProcessTaskStateObserver(client);
> 
> Missing the adoptRef(), so this will leak.

Oof. Will fix.

> > Source/WebKit/Shared/Cocoa/ProcessTaskStateObserver.mm:95
> > +void ProcessTaskStateObserver::invalidate()
> 
> Who is calling this? I could not find a caller.

No one. The only client so far is WebProcess, which is never destroyed, so there's no good place to call invalidate (nor any need).

> > Source/WebKit/Shared/Cocoa/ProcessTaskStateObserver.mm:104
> > +    return makeRefPtr(m_client);
> 
> Note that this is not generally thread safe, what guarantees that the
> destructor of m_client is not currently running on another thread.

The only guarantee is that the client has to call invalidate() before their own destructor is called (because at that point their own refcount will be zero, and you can't ref a zero ref count object). Again, since the only client so far is WebProcess, the client is never destroyed, so NBD, but if any one else adopts this object, they'll need to beware.

> > Source/WebKit/WebProcess/WebProcess.h:455
> > +    void derefClient() final { ref(); }
> 
> should be deref() :(

Gah, copy pasta.
Comment 5 Jer Noble 2019-09-26 12:24:27 PDT
Created attachment 379667 [details]
Patch
Comment 6 Jer Noble 2019-09-26 12:49:35 PDT
Created attachment 379669 [details]
Patch
Comment 7 Jer Noble 2019-09-26 15:01:36 PDT
Created attachment 379685 [details]
Patch
Comment 8 Chris Dumez 2019-09-26 15:13:35 PDT
Comment on attachment 379685 [details]
Patch

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

r=me with changes. Also please fix build failures on EWS.

> Source/WebKit/Shared/Cocoa/ProcessTaskStateObserver.mm:84
> +    invalidate();

Why not simply m_delegate.get().taskStateChangedCallback = nil; ? We don't really need to lock and null out the client.

> Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:318
> +    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), [assertion = WTFMove(uiProcessAssertion)] { });

I seem to remember you need to explicitly call [assertion invalidate]; before deallocating it.
Comment 9 Jer Noble 2019-09-26 15:17:35 PDT
(In reply to Chris Dumez from comment #8)
> Comment on attachment 379685 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=379685&action=review
> 
> r=me with changes. Also please fix build failures on EWS.
> 
> > Source/WebKit/Shared/Cocoa/ProcessTaskStateObserver.mm:84
> > +    invalidate();
> 
> Why not simply m_delegate.get().taskStateChangedCallback = nil; ? We don't
> really need to lock and null out the client.

Probably not given the caller of setTaskState() is also holding a ref to the observer.

> > Source/WebKit/WebProcess/cocoa/WebProcessCocoa.mm:318
> > +    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), [assertion = WTFMove(uiProcessAssertion)] { });
> 
> I seem to remember you need to explicitly call [assertion invalidate];
> before deallocating it.

Will do.
Comment 10 Jer Noble 2019-09-26 15:53:09 PDT
Created attachment 379692 [details]
Patch for landing
Comment 11 Jer Noble 2019-09-26 16:39:34 PDT
Created attachment 379696 [details]
Patch for landing
Comment 12 WebKit Commit Bot 2019-09-27 09:27:52 PDT
Comment on attachment 379696 [details]
Patch for landing

Clearing flags on attachment: 379696

Committed r250428: <https://trac.webkit.org/changeset/250428>
Comment 13 WebKit Commit Bot 2019-09-27 09:27:53 PDT
All reviewed patches have been landed.  Closing bug.