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
Patch (4.66 KB, patch)
2021-09-02 20:34 PDT, Myles C. Maxfield
no flags
Patch (4.70 KB, patch)
2021-09-03 13:13 PDT, Myles C. Maxfield
no flags
Patch (4.59 KB, patch)
2021-09-03 21:20 PDT, Myles C. Maxfield
no flags
Myles C. Maxfield
Comment 1 2021-09-02 20:15:09 PDT
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
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
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
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
Note You need to log in before you can comment on or make changes to this bug.