Repository navigation
fix(share): read a web link that loadItem returns as Data - #1066
Merged
Merged
Conversation
Two ShareInputTests cases failed on main: "A web link prefills the message" and "A link wins over the page title Safari sends beside it". For an NSURL registered as public.url, loadItem with no class to coerce to returns the URL's UTF-8 bytes as NSConcreteData, not a URL object. loadWebURL had no Data case, so it dropped the link and the prefill fell back to the page title, or to nil. Read Data with URL(dataRepresentation:relativeTo:), the same way loadText already reads Data.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two
ShareInputTestscases fail onmain: "A web link prefills the message" and "A link wins over the page title Safari sends beside it". The parser was wrong, not the expectations.For an
NSURLregistered aspublic.url,loadItem(forTypeIdentifier:)with no class to coerce to returns the URL's UTF-8 bytes (NSConcreteData, 25 bytes forhttps://example.com/a?b=1), not a URL object.loadWebURLmatched onlyURL,NSURLandString, so it returned nil. The prefill then fell back to the page title, or to nil when the link was the only provider.The fix adds a
Datacase that reads the bytes withURL(dataRepresentation:relativeTo:), matching howloadTextalready handlesData. The file-URL check still runs afterwards, so a file shared from Files still isn't treated as message text.Both tests landed with the parser in #1041 and neither file has changed since. I reproduced the failure with
swift teston macOS; none of this repo's GitHub workflows runs the FlipcashCore suite, so I haven't checked how the parser behaves with Safari's own provider on iOS. The new case only adds a shape it accepts, so a provider that hands back aURLtakes the same path as before.