Skip to content

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

christianliebel
Copy link
Contributor

@christianliebel christianliebel commented Sep 1, 2024

9b97de8

Parse "lang" member of Web Application Manifest
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)):

9b97de8

Misc iOS, visionOS, tvOS & watchOS macOS Linux Windows
✅ 🧪 style ❌ 🛠 ios ❌ 🛠 mac ✅ 🛠 wpe ✅ 🛠 win
✅ 🧪 bindings ❌ 🛠 ios-sim ❌ 🛠 mac-AS-debug ❌ 🧪 wpe-wk2 ⏳ 🧪 win-tests
✅ 🧪 webkitperl ❌ 🧪 ios-wk2 ❌ 🧪 api-mac ✅ 🧪 api-wpe
❌ 🧪 ios-wk2-wpt ❌ 🧪 mac-wk1 ✅ 🛠 wpe-cairo
✅ 🛠 🧪 jsc ❌ 🧪 api-ios ❌ 🧪 mac-wk2 ✅ 🛠 gtk
✅ 🛠 🧪 jsc-arm64 ❌ 🛠 vision ❌ 🧪 mac-AS-debug-wk2 ✅ 🧪 gtk-wk2
❌ 🛠 vision-sim ❌ 🧪 mac-wk2-stress ❌ 🧪 api-gtk
⏳ 🧪 vision-wk2 ❌ 🧪 mac-intel-wk2 🛠 playstation
❌ 🛠 tv ❌ 🛠 mac-safer-cpp ✅ 🛠 jsc-armv7
❌ 🛠 tv-sim ✅ 🧪 jsc-armv7-tests
❌ 🛠 watch
❌ 🛠 watch-sim

@christianliebel christianliebel changed the title Parse "lang" member of Web Application Manifest Parse "lang" member of Web Application Manifest https://bugs.webkit.org/show_bug.cgi?id=278984 Sep 5, 2024
@christianliebel christianliebel force-pushed the eng/Parse-lang-member-of-Web-Application-Manifest branch from 025d6d5 to fb614e0 Compare September 5, 2024 11:50
@christianliebel christianliebel changed the title Parse "lang" member of Web Application Manifest https://bugs.webkit.org/show_bug.cgi?id=278984 Parse "lang" member of Web Application Manifest Sep 5, 2024
@christianliebel christianliebel force-pushed the eng/Parse-lang-member-of-Web-Application-Manifest branch from fb614e0 to 320394e Compare September 5, 2024 11:53
@annevk
Copy link
Contributor

annevk commented Sep 5, 2024

Thanks! Looks good, but ideally someone from JSC reviews those bits.

return { };
}

return JSC::canonicalizeUnicodeLocaleID(lang.utf8());
Copy link
Member

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);
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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?

Copy link
Contributor

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;
Copy link
Member

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?

Copy link
Contributor

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.

Copy link
Member

@Constellation Constellation left a 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

@christianliebel christianliebel force-pushed the eng/Parse-lang-member-of-Web-Application-Manifest branch from 320394e to e61f53d Compare June 26, 2025 11:06
@webkit-ews-buildbot webkit-ews-buildbot added the merging-blocked Applied to prevent a change from being merged label Jun 26, 2025
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)):
@christianliebel christianliebel force-pushed the eng/Parse-lang-member-of-Web-Application-Manifest branch from e61f53d to 9b97de8 Compare July 1, 2025 07:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merging-blocked Applied to prevent a change from being merged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants