-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Parse "lang" member of Web Application Manifest #33004
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Parse "lang" member of Web Application Manifest #33004
Conversation
EWS run on previous version of this PR (hash 025d6d5) |
Source/WebCore/Modules/applicationmanifest/ApplicationManifestParser.cpp
Outdated
Show resolved
Hide resolved
025d6d5
to
fb614e0
Compare
EWS run on previous version of this PR (hash fb614e0) |
fb614e0
to
320394e
Compare
EWS run on previous version of this PR (hash 320394e) |
Thanks! Looks good, but ideally someone from JSC reviews those bits. |
return { }; | ||
} | ||
|
||
return JSC::canonicalizeUnicodeLocaleID(lang.utf8()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Converting to UTF-8 on the way in is a peculiar step in canonicalizing this ID, and even an unnecessarily inefficient one since a structurally valid language tag is guaranteed not to have non-ASCII characters and likely is almost always already stored as an 8-bit string, while the utf8
function always returns newly allocated memory than then has to be deallocated. Building this inefficient idiom into the interface between JavaScriptCore and WebCore isn’t great, even for something trivial like this. The conversion step is required only because the existing function from IntlObject.h
happens to take a CString
. I think we should have a function that takes a String
or StringView
that does the same operation that we export from IntlObject.h
, even if for now it has creates a CString
internally for reasons of expediency; it would be easy to write a version that doesn’t unnecessarily allocate and deallocate memory for an extra copy of the string in the common case, though.
@@ -203,6 +203,11 @@ class ApplicationManifestParserTest : public testing::Test { | |||
EXPECT_EQ(expectedValue, value); | |||
} | |||
|
|||
void testLang(const String& rawJSON, const String& expectedValue) | |||
{ | |||
EXPECT_EQ(expectedValue, parseTopLevelProperty("lang"_s, rawJSON).lang); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t understand why we are adding the parsing, but it has no effect on the web platform. It’s very strange that the only tests are in C++. Is there some web-platform-visible effect of the parsing that can be tested more end to end?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change extends the Web Application Manifest, which is evaluated when a user adds a website to the home screen. Safari uses these values to determine the icon, suggested name, etc., for the web clip. After parsing, all values are passed to the platform-specific side, so there are indeed no web-platform-visible effects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you contributing a pull request that parses more and hoping to influence the Safari developers to make use of the new values?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it's more for standards compliance. Christian is a co-editor with me on the Manifest spec. On the W3C side, we require implementation before we add things to the spec. At the same time, I'm coordinating with Safari folks and letting them know of the changes - but it's up to them if they actually adopt them (i.e., that's a product decision for Safari, with the usual disclaimer that "Apple doesn't comment on future features and products"). Should Safari choose to use these values, they are there.
@@ -74,6 +74,7 @@ WK_CLASS_AVAILABLE(macos(10.13.4), ios(11.3)) | |||
|
|||
@property (nonatomic, readonly, nullable, copy) NSString *rawJSON; | |||
@property (nonatomic, readonly) _WKApplicationManifestDirection dir; | |||
@property (nonatomic, readonly, nullable, copy) NSString *lang; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to understand the big picture. Why are we adding all these getters to this Objective-C class. What is this SPI for? Is this a building block for some feature we are working on?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is for create the UI that Safari uses when presenting the Add to Home Screen/Dock UI. The larger picture is to provide language hints, if needed, which would only have an impact potentially accessibility: the name of the application being read correctly in some language, for instance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me on JSC change
320394e
to
e61f53d
Compare
EWS run on previous version of this PR (hash e61f53d) |
https://bugs.webkit.org/show_bug.cgi?id=278984 Reviewed by NOBODY (OOPS!). Implements the "lang" member to the web application manifest parser per spec: https://www.w3.org/TR/appmanifest/#lang-member Along with the required encoders/decoders and API tests. * Source/JavaScriptCore/CMakeLists.txt: * Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj: * Source/JavaScriptCore/runtime/IntlObject.h: * Source/WebCore/Modules/applicationmanifest/ApplicationManifest.h: * Source/WebCore/Modules/applicationmanifest/ApplicationManifestParser.cpp: (WebCore::ApplicationManifestParser::parseManifest): (WebCore::ApplicationManifestParser::parseLang): * Source/WebCore/Modules/applicationmanifest/ApplicationManifestParser.h: * Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in: * Source/WebKit/UIProcess/API/Cocoa/_WKApplicationManifest.h: * Source/WebKit/UIProcess/API/Cocoa/_WKApplicationManifest.mm: (-[_WKApplicationManifest initWithCoder:]): (-[_WKApplicationManifest encodeWithCoder:]): (-[_WKApplicationManifest lang]): * Tools/TestWebKitAPI/Tests/WebCore/ApplicationManifestParser.cpp: (ApplicationManifestParserTest::testLang): (TEST_F(ApplicationManifestParserTest, Lang)):
e61f53d
to
9b97de8
Compare
EWS run on current version of this PR (hash 9b97de8) |
9b97de8
9b97de8
🛠 playstation