Summary: | [iOS] Support dropping contact card data (public.vcard) in editable content | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Wenson Hsieh <wenson_hsieh> | ||||||||||
Component: | HTML Editing | Assignee: | Wenson Hsieh <wenson_hsieh> | ||||||||||
Status: | RESOLVED FIXED | ||||||||||||
Severity: | Normal | CC: | aestes, bdakin, commit-queue, megan_gardner, rniwa, thorton, webkit-bug-importer, wenson_hsieh | ||||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||||
Version: | WebKit Nightly Build | ||||||||||||
Hardware: | Unspecified | ||||||||||||
OS: | Unspecified | ||||||||||||
Attachments: |
|
Description
Wenson Hsieh
2018-12-10 14:55:03 PST
For added context, our current behavior when dropping a vCard in both rich and plain editable elements is that we dump the entire contents of the vCard as plain text :( The desired behavior is probably: • If there is a URL accompanying the vCard, dropping into a rich contenteditable with attachments enabled should produce a link and an attachment element, and dropping into a rich contenteditable without attachments should insert just a link. • If there is no URL accompanying the vCard, dropping into a rich contenteditable area should insert an attachment element, and dropping into a rich contenteditable without attachments enabled should do nothing. • If there is a URL accompanying the vCard, dropping into a plain contenteditable should insert the URL. • If there is no URL accompanying the vCard, dropping into a plain contenteditable should do nothing. Created attachment 357080 [details]
First pass
Created attachment 357084 [details]
Try to fix macOS builds
Created attachment 357085 [details]
Fix 32-bit macOS build
Comment on attachment 357085 [details] Fix 32-bit macOS build View in context: https://bugs.webkit.org/attachment.cgi?id=357085&action=review > Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm:28 > +#if WK_API_ENABLED && !PLATFORM(WATCHOS) && !PLATFORM(TVOS) isn't this just PLATFORM(IOS) now? WK_API_ENABLED is always true there, and that excludes watch and tv > Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm:1851 > + [contact setFamilyName:@"Bitdiddle"]; 🤨 (In reply to Tim Horton from comment #5) > Comment on attachment 357085 [details] > Fix 32-bit macOS build > > View in context: > https://bugs.webkit.org/attachment.cgi?id=357085&action=review > > > Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm:28 > > +#if WK_API_ENABLED && !PLATFORM(WATCHOS) && !PLATFORM(TVOS) > > isn't this just PLATFORM(IOS) now? > > WK_API_ENABLED is always true there, and that excludes watch and tv OH you want mac too. OK so (PLATFORM(MAC) || PLATFORM(IOS)) && WK_API_ENABLED > > Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm:1851 > > + [contact setFamilyName:@"Bitdiddle"]; > > 🤨 Comment on attachment 357085 [details] Fix 32-bit macOS build View in context: https://bugs.webkit.org/attachment.cgi?id=357085&action=review >>> Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm:28 >>> +#if WK_API_ENABLED && !PLATFORM(WATCHOS) && !PLATFORM(TVOS) >> >> isn't this just PLATFORM(IOS) now? >> >> WK_API_ENABLED is always true there, and that excludes watch and tv > > OH you want mac too. OK so (PLATFORM(MAC) || PLATFORM(IOS)) && WK_API_ENABLED Sounds good! Changed to (PLATFORM(MAC) || PLATFORM(IOS)) && WK_API_ENABLED >>> Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm:1851 >>> + [contact setFamilyName:@"Bitdiddle"]; >> >> 🤨 > > Heh, I do like my SICP names. Changed to a more generic "Foo Bar" Created attachment 357258 [details]
Patch for landing
Comment on attachment 357258 [details] Patch for landing Clearing flags on attachment: 357258 Committed r239184: <https://trac.webkit.org/changeset/239184> |