WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
202279
[iOS] Lock screen controls can fail to play web content
https://bugs.webkit.org/show_bug.cgi?id=202279
Summary
[iOS] Lock screen controls can fail to play web content
Jer Noble
Reported
2019-09-26 11:15:21 PDT
[iOS] Lock screen controls can fail to play web content
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
Show Obsolete
(5)
View All
Add attachment
proposed patch, testcase, etc.
Jer Noble
Comment 1
2019-09-26 11:22:36 PDT
<
rdar://50920870
>
Jer Noble
Comment 2
2019-09-26 11:23:24 PDT
Created
attachment 379663
[details]
Patch
Chris Dumez
Comment 3
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() :(
Jer Noble
Comment 4
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.
Jer Noble
Comment 5
2019-09-26 12:24:27 PDT
Created
attachment 379667
[details]
Patch
Jer Noble
Comment 6
2019-09-26 12:49:35 PDT
Created
attachment 379669
[details]
Patch
Jer Noble
Comment 7
2019-09-26 15:01:36 PDT
Created
attachment 379685
[details]
Patch
Chris Dumez
Comment 8
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.
Jer Noble
Comment 9
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.
Jer Noble
Comment 10
2019-09-26 15:53:09 PDT
Created
attachment 379692
[details]
Patch for landing
Jer Noble
Comment 11
2019-09-26 16:39:34 PDT
Created
attachment 379696
[details]
Patch for landing
WebKit Commit Bot
Comment 12
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
>
WebKit Commit Bot
Comment 13
2019-09-27 09:27:53 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug