WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
229848
FontFaceSet.has() needs to react to style changes
https://bugs.webkit.org/show_bug.cgi?id=229848
Summary
FontFaceSet.has() needs to react to style changes
Myles C. Maxfield
Reported
2021-09-02 20:11:50 PDT
FontFaceSet.has() needs to react to style changes
Attachments
Patch
(4.56 KB, patch)
2021-09-02 20:15 PDT
,
Myles C. Maxfield
no flags
Details
Formatted Diff
Diff
Patch
(4.66 KB, patch)
2021-09-02 20:34 PDT
,
Myles C. Maxfield
no flags
Details
Formatted Diff
Diff
Patch
(4.70 KB, patch)
2021-09-03 13:13 PDT
,
Myles C. Maxfield
no flags
Details
Formatted Diff
Diff
Patch
(4.59 KB, patch)
2021-09-03 21:20 PDT
,
Myles C. Maxfield
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Myles C. Maxfield
Comment 1
2021-09-02 20:15:09 PDT
Created
attachment 437238
[details]
Patch
EWS Watchlist
Comment 2
2021-09-02 20:16:14 PDT
This patch modifies the imported WPT tests. Please ensure that any changes on the tests (not coming from a WPT import) are exported to WPT. Please see
https://trac.webkit.org/wiki/WPTExportProcess
Myles C. Maxfield
Comment 3
2021-09-02 20:34:54 PDT
Created
attachment 437239
[details]
Patch
Sam Weinig
Comment 4
2021-09-03 09:47:58 PDT
Comment on
attachment 437239
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=437239&action=review
> Source/WebCore/css/FontFaceSet.cpp:110 > + auto protect = m_backing;
Same as the others, would use Ref protect = m_backing;
> Source/WebCore/css/FontFaceSet.cpp:113 > return m_backing->hasFace(face.backing());
Seems like this should use protect to?
Myles C. Maxfield
Comment 5
2021-09-03 13:13:11 PDT
Created
attachment 437305
[details]
Patch
Darin Adler
Comment 6
2021-09-03 16:07:29 PDT
Comment on
attachment 437305
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=437305&action=review
I don’t understand why m_backing is not sufficient protection and why we need a local variable.
> Source/WebCore/css/FontFaceSet.cpp:113 > - return m_backing->hasFace(face.backing()); > + Ref protect = m_backing; > + if (face.backing().cssConnection()) > + protect->updateStyleIfNeeded(); > + return protect->hasFace(face.backing());
I don’t understand why m_backing is not sufficient protection and why we need a local variable. A "protect" idiom should be very rarely needed. Instead the top level callers of functions need to use Ref or RefPtr. If FontFaceSet *itself* might be dereferenced as a side effect of updating style, then the correct question is who could call this on a FontFaceSet without holding a reference to the FontFaceSet. If the call is from JavaScript, then the JavaScript bindings themselves will be holding a reference to the FontFaceSet, so it would have to be a call from within WebCore.
Myles C. Maxfield
Comment 7
2021-09-03 21:17:40 PDT
Comment on
attachment 437305
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=437305&action=review
>> Source/WebCore/css/FontFaceSet.cpp:113 >> + return protect->hasFace(face.backing()); > > I don’t understand why m_backing is not sufficient protection and why we need a local variable. A "protect" idiom should be very rarely needed. Instead the top level callers of functions need to use Ref or RefPtr. > > If FontFaceSet *itself* might be dereferenced as a side effect of updating style, then the correct question is who could call this on a FontFaceSet without holding a reference to the FontFaceSet. If the call is from JavaScript, then the JavaScript bindings themselves will be holding a reference to the FontFaceSet, so it would have to be a call from within WebCore.
You're right - the only callers of this are from JS. So, JS will maintain a ref to FontFaceSet, and FontFaceSet will maintain a ref to CSSFontFaceSet. So this doesn't need to be protected.
Myles C. Maxfield
Comment 8
2021-09-03 21:20:16 PDT
Created
attachment 437337
[details]
Patch
Myles C. Maxfield
Comment 9
2021-09-03 22:00:10 PDT
Comment on
attachment 437305
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=437305&action=review
>>> Source/WebCore/css/FontFaceSet.cpp:113 >>> + return protect->hasFace(face.backing()); >> >> I don’t understand why m_backing is not sufficient protection and why we need a local variable. A "protect" idiom should be very rarely needed. Instead the top level callers of functions need to use Ref or RefPtr. >> >> If FontFaceSet *itself* might be dereferenced as a side effect of updating style, then the correct question is who could call this on a FontFaceSet without holding a reference to the FontFaceSet. If the call is from JavaScript, then the JavaScript bindings themselves will be holding a reference to the FontFaceSet, so it would have to be a call from within WebCore. > > You're right - the only callers of this are from JS. So, JS will maintain a ref to FontFaceSet, and FontFaceSet will maintain a ref to CSSFontFaceSet. So this doesn't need to be protected.
https://bugs.webkit.org/show_bug.cgi?id=229911
EWS
Comment 10
2021-09-09 02:38:48 PDT
Committed
r282204
(
241491@main
): <
https://commits.webkit.org/241491@main
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 437337
[details]
.
Radar WebKit Bug Importer
Comment 11
2021-09-09 02:39:34 PDT
<
rdar://problem/82916442
>
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