WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
196232
FontFace constructor throws an exception when there is a name which starts with a number
https://bugs.webkit.org/show_bug.cgi?id=196232
Summary
FontFace constructor throws an exception when there is a name which starts wi...
Ryosuke Niwa
Reported
2019-03-25 17:16:31 PDT
new FontFace('x 2y', 'url(abc.woff2)') throws an exception in Safari 12.2 but not in Chrome or Firefox.
Attachments
Reduction
(132 bytes, text/html)
2019-03-26 14:53 PDT
,
Ryosuke Niwa
no flags
Details
Patch
(6.51 KB, patch)
2019-03-28 17:20 PDT
,
Myles C. Maxfield
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Ryosuke Niwa
Comment 1
2019-03-25 20:37:47 PDT
Huh, Blink doesn't seem to do any validation for the font name at all :(
https://github.com/chromium/chromium/blob/master/third_party/blink/renderer/core/css/font_face.cc#L200
Myles C. Maxfield
Comment 2
2019-03-25 21:28:57 PDT
Oh, it's because there's a space in there.
Myles C. Maxfield
Comment 3
2019-03-25 21:40:24 PDT
This is because of the historical difference between font-family:foo; and font-family:”foo”; FontFace::parseString() is passing its argument directly to consumeFontFamilyDescriptor() in CSSPropertyParser.cpp, which parses the string according to the first form. The first form doesn’t allow spaces. We should adopt the Chrome/Firefox behavior, and the spec should be clarified here.
Ryosuke Niwa
Comment 4
2019-03-26 14:53:40 PDT
Created
attachment 366004
[details]
Reduction In Chrome & Firefox, this file would say "OK". In WebKit, it does not.
Radar WebKit Bug Importer
Comment 5
2019-03-26 14:54:06 PDT
<
rdar://problem/49293978
>
Ryosuke Niwa
Comment 6
2019-03-26 15:38:18 PDT
Relevant spec text:
https://drafts.csswg.org/css-font-loading/#font-face-constructor
> 1. ... > Parse the family argument, and the members of the descriptors argument, according to > the grammars of the corresponding descriptors of the CSS @font-face rule > ...
https://drafts.csswg.org/css-fonts-4/#font-face-rule
https://drafts.csswg.org/css-fonts-4/#font-family-desc
https://drafts.csswg.org/css-fonts-4/#family-name-value
Then finally,
https://drafts.csswg.org/css-fonts-4/#family-name-syntax
> Font family names other than generic families must either be given quoted as <string>s, or unquoted as a sequence of one or more identifiers. > ... > If a sequence of identifiers is given as a <family-name>, the computed value is the name converted to a string by joining all the identifiers in the sequence by single spaces.
Ryosuke Niwa
Comment 7
2019-03-26 15:39:09 PDT
We probably need to amend the following text for FontFace constructor:
https://drafts.csswg.org/css-font-loading/#font-face-constructor
> If any of them fail to parse correctly, reject font face’s [[FontStatusPromise]] with a DOMException named "SyntaxError", set font face’s corresponding attributes to the empty string, and set font face’s status attribute to "error". Otherwise, set font face’s corresponding attributes to the serialization of the parsed values.
Myles C. Maxfield
Comment 8
2019-03-28 13:55:01 PDT
https://github.com/w3c/csswg-drafts/issues/3776
Myles C. Maxfield
Comment 9
2019-03-28 17:20:52 PDT
Created
attachment 366226
[details]
Patch
WebKit Commit Bot
Comment 10
2019-03-28 19:26:53 PDT
Comment on
attachment 366226
[details]
Patch Clearing flags on attachment: 366226 Committed
r243637
: <
https://trac.webkit.org/changeset/243637
>
WebKit Commit Bot
Comment 11
2019-03-28 19:26:55 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