SSIA
<rdar://problem/49573377>
Created attachment 366679 [details] Patch
Created attachment 366694 [details] Fix the WPE build
Created attachment 366695 [details] Really fix the WPE build?
Comment on attachment 366695 [details] Really fix the WPE build? View in context: https://bugs.webkit.org/attachment.cgi?id=366695&action=review > Source/WebKit/UIProcess/API/APIWebsitePolicies.cpp:65 > + WTF::String name = field.name(); > + WTF::String value = field.value(); > + if (auto newHeaderField = WebCore::HTTPHeaderField::create(WTFMove(name), WTFMove(value))) > + customHeaderFields.append(WTFMove(*newHeaderField)); Shouldn't this use HTTPHeaderField copy constructor
Comment on attachment 366695 [details] Really fix the WPE build? View in context: https://bugs.webkit.org/attachment.cgi?id=366695&action=review >> Source/WebKit/UIProcess/API/APIWebsitePolicies.cpp:65 >> + customHeaderFields.append(WTFMove(*newHeaderField)); > > Shouldn't this use HTTPHeaderField copy constructor It rather should, but HTTPHeaderField doesn't currently have a copy constructor, so I'll add one and use it here.
(In reply to Tim Horton from comment #5) > Comment on attachment 366695 [details] > Really fix the WPE build? > > View in context: > https://bugs.webkit.org/attachment.cgi?id=366695&action=review > > > Source/WebKit/UIProcess/API/APIWebsitePolicies.cpp:65 > > + WTF::String name = field.name(); > > + WTF::String value = field.value(); > > + if (auto newHeaderField = WebCore::HTTPHeaderField::create(WTFMove(name), WTFMove(value))) > > + customHeaderFields.append(WTFMove(*newHeaderField)); > > Shouldn't this use HTTPHeaderField copy constructor 👍🏻 Changed to use the default copy constructor.
Created attachment 366746 [details] Patch for EWS
Comment on attachment 366746 [details] Patch for EWS Clearing flags on attachment: 366746 Committed r243909: <https://trac.webkit.org/changeset/243909>