[Webkit-unassigned] [Bug 184550] [Attachment Support] WebEditingDelegate's shouldInsertNode cannot access dragged file content

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=184550

--- Comment #3 from Wenson Hsieh <wenson_hsieh at apple.com> ---
(In reply to Jonathan Hammer from comment #2)
> Yes, we would like to avoid using SPI. Thanks for your suggested
> workarounds. Some quick feedback as to why they probably aren't feasible for
> us right now:
> 
> 1. We use WebKit1 as a WYSIWYG HTML email editor and allow the user to edit
> the HTML source. We disable JavaScript in the editor because HTML email
> doesn't support it anyway. We'd like to avoid enabling JS for the purposes
> of handling this drag, since it means we'd have to fight with any JS the
> user had written into their document (or sanitize it away). It is cleaner
> for us to work "one level up" in the ObjC API instead of running our app
> logic inside the same JS context that the user's code is executing.
> 

Right — there's no public API to enable only JS supplied from native code (and not page markup). Now...as a workaround, there does exist the `javaScriptMarkupEnabled` property for WebKit1 in WebPreferencesPrivate.h, which would allow you to achieve this behavior (disable JS from the page, but enable any JS injected natively via WebView API/SPI).

> 2. WK2 is the future, but the ObjC API is not nearly as rich as WK1 (at
> least when it comes to editing), and we're not able to get the same
> functionality -- not yet, at least. My feeling is that WK2 would prefer that
> the developer use JS to do the heavy lifting, rather than ObjC API. That
> means big rewrites for us and runs us into the same concerns mentioned in #1
> above.

Indeed. For instance, we support mechanisms such as input events (https://www.w3.org/TR/input-events-2/) which would allow JavaScript developers to customize the behavior of various editing operations by calling preventDefault() on the `beforeinput` event, and using document.execCommand() to carry out DOM mutations as needed.

> 
> It would be great to have a supported solution that didn't rely on SPI. I
> understand there is probably not appetite to invest time into making this
> happen in WebKit1.
> 

Correct. We hope that more clients will be able to make the transition to WebKit2 :)

> I think prior to 10.12, the "node" parameter would contain one child node
> (div? span?) per attachment, with the .textContent of each child node equal
> to the file URL of the attachment. I don't know if it's possible to go back
> to that, but it was a serviceable solution for our purposes.

The fact that we were exposing raw file paths to web content was actually a security/privacy bug that we fixed recently, in 10.13.4. That we were accidentally exposing our own non-standard <attachment> elements to web developers in general was also an issue that we fixed in this time frame.

> 
> Thanks again.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180412/917e983d/attachment-0002.html>