[Webkit-unassigned] [Bug 139443] [GTK] Add API to set the web view editable into WebKit2 GTK+ API

[bugzilla-daemon at webkit.org]

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

--- Comment #12 from Tomas Popela <tpopela at redhat.com> ---
(In reply to comment #11)
> hmm, after reading the api again, I wonder if it would be better to use
> webkit_web_view_is_editable()

That makes sense.

> There are 3 returns here :-) I would reorganiza this a bit. The last one is
> redundant so I would just remove it. I don't understand the part "You can
> change @web_view's document through #WebKitWebInspector or
> #WebKitWebExtension regardless this setting". I guess you mean that you can
> change the html so make the document editable.

That was meant to highlight that the content of the web view is not "readonly", so you can change it. But it makes sense to not have it there.

> We could explain how
> this affect what the document contains, for example, what happens if the
> body tag contains contentEditable=True? does this method return true or
> false? (We could probably add a test case for that indeed).

In the case that the editable property is set to FALSE and we will load the page with contenteditable set on body it will return FALSE. It could return TRUE only in case that the contenteditable is set on body. But no-one is doing that (other ports).

> So, we are only testing the setter, but not the getter. We should check that
> by default is_editable returns FALSE as the doc says, and that after calling
> set_editable with TRUE, is_editable also return TRUE. It would be nice to
> check also that the web view can override the document, so that if body has
> contentEditable=false, making the view editable allows to edit the web view.
> So maybe it's better to add specific test cases for this, instead of reusing
> the selection ones.

Ok, makes sense.

-- 
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/20150116/a33637ee/attachment-0002.html>