* fine grained control of webkit browsing
@ 2018-06-19 15:49 Perry E. Metzger
2018-06-19 16:19 ` Ricardo Wurmus
0 siblings, 1 reply; 11+ messages in thread
From: Perry E. Metzger @ 2018-06-19 15:49 UTC (permalink / raw)
To: emacs-devel
I'm playing a bit with xwidgets webkit browsing for the first time
(because I have Veshboo's patches working for myself on MacOS under
the master branch) and I'm wondering a few things about the
architecture:
1) Say one wants to browse the contents of a buffer, is there a way
to do that?
2) Say one wants to do things like viewing something with javascript
off and without loading remote elements (say because one wants to
safely view some HTML email). What does one need to do to get this
to work?
The documentation on this stuff is very sparse, or if there is more
documentation, I haven't been able to find it.
Perry
--
Perry E. Metzger perry@piermont.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: fine grained control of webkit browsing
2018-06-19 15:49 fine grained control of webkit browsing Perry E. Metzger
@ 2018-06-19 16:19 ` Ricardo Wurmus
2018-06-19 16:37 ` Perry E. Metzger
2018-06-19 22:57 ` Richard Stallman
0 siblings, 2 replies; 11+ messages in thread
From: Ricardo Wurmus @ 2018-06-19 16:19 UTC (permalink / raw)
To: Perry E. Metzger; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 938 bytes --]
Perry E. Metzger <perry@piermont.com> writes:
> 2) Say one wants to do things like viewing something with javascript
> off and without loading remote elements (say because one wants to
> safely view some HTML email). What does one need to do to get this
> to work?
The widget is not fully integrated into Emacs. The extent to which one
can conveniently communicate with the widget is by sending a string
containing a JavaScript program to the widget and have it return a
value. Everything else requires exposing Webkit API features to Elisp.
Attached is an old patch that I never submitted that allows one to set
webkit settings via Elisp. Unfortunately, disabling JavaScript for the
widget also disables JavaScript evaluation of strings that are sent from
Emacs – we use JavaScript for telling the widget to scroll, for example.
(See “xwidget-webkit-scroll-bottom” or “xwidget-webkit-show-element”.)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: settings.patch --]
[-- Type: text/x-patch, Size: 7418 bytes --]
commit b1d2a1ad4a489838027e2f897f65190509a3c34f
Author: Ricardo Wurmus <rekado@elephly.net>
Date: Sat Oct 29 19:08:54 2016 +0200
webkit set settings
diff --git a/lisp/xwidget.el b/lisp/xwidget.el
index a4214f054a..11dfc061f2 100644
--- a/lisp/xwidget.el
+++ b/lisp/xwidget.el
@@ -39,6 +39,8 @@
(declare-function xwidget-buffer "xwidget.c" (xwidget))
(declare-function xwidget-size-request "xwidget.c" (xwidget))
(declare-function xwidget-resize "xwidget.c" (xwidget new-width new-height))
+(declare-function xwidget-webkit-set-settings "xwidget.c"
+ (xwidget settings))
(declare-function xwidget-webkit-execute-script "xwidget.c"
(xwidget script &optional callback))
(declare-function xwidget-webkit-goto-uri "xwidget.c" (xwidget uri))
diff --git a/src/xwidget.c b/src/xwidget.c
index 4fa906a9f0..fd0ca3edf1 100644
--- a/src/xwidget.c
+++ b/src/xwidget.c
@@ -751,6 +751,84 @@ argument procedure FUN.*/)
return Qnil;
}
+DEFUN ("xwidget-webkit-set-settings",
+ Fxwidget_webkit_set_settings, Sxwidget_webkit_set_settings,
+ 2, 2, 0,
+ doc: /* Set the settings of the Webkit XWIDGET view to the
+values specified in ALIST.*/)
+ (Lisp_Object xwidget, Lisp_Object alist)
+{
+ WEBKIT_FN_INIT ();
+ CHECK_LIST (alist);
+
+ WebKitSettings *settings = webkit_web_view_get_settings (WEBKIT_WEB_VIEW (xw->widget_osr));
+
+ for (int i = 0; CONSP (alist); alist = XCDR (alist))
+ {
+ Lisp_Object elt, key, val;
+
+ elt = XCAR (alist);
+ key = Fcar (elt);
+ CHECK_SYMBOL (key);
+ val = Fcdr (elt);
+
+ // TODO: use a macro instead?
+ if (EQ (key, Qwebkit_allow_file_access_from_file_urls))
+ webkit_settings_set_allow_file_access_from_file_urls (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_allow_modal_dialogs))
+ webkit_settings_set_allow_modal_dialogs (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_allow_file_access_from_file_urls))
+ webkit_settings_set_allow_file_access_from_file_urls (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_allow_modal_dialogs))
+ webkit_settings_set_allow_modal_dialogs (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_allow_universal_access_from_file_urls))
+ webkit_settings_set_allow_universal_access_from_file_urls (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_auto_load_images))
+ webkit_settings_set_auto_load_images (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_draw_compositing_indicators))
+ webkit_settings_set_draw_compositing_indicators (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_enable_accelerated_2d_canvas))
+ webkit_settings_set_enable_accelerated_2d_canvas (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_enable_caret_browsing))
+ webkit_settings_set_enable_caret_browsing (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_enable_developer_extras))
+ webkit_settings_set_enable_developer_extras (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_enable_dns_prefetching))
+ webkit_settings_set_enable_dns_prefetching (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_enable_frame_flattening))
+ webkit_settings_set_enable_frame_flattening (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_enable_javascript))
+ webkit_settings_set_enable_javascript (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_enable_private_browsing))
+ webkit_settings_set_enable_private_browsing (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_enable_webaudio))
+ webkit_settings_set_enable_webaudio (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_enable_webgl))
+ webkit_settings_set_enable_webgl (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_enable_write_console_messages_to_stdout))
+ webkit_settings_set_enable_write_console_messages_to_stdout (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_enable_xss_auditor))
+ webkit_settings_set_enable_xss_auditor (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_javascript_can_access_clipboard))
+ webkit_settings_set_javascript_can_access_clipboard (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_javascript_can_open_windows_automatically))
+ webkit_settings_set_javascript_can_open_windows_automatically (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_load_icons_ignoring_image_load_setting))
+ webkit_settings_set_load_icons_ignoring_image_load_setting (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_media_playback_requires_user_gesture))
+ webkit_settings_set_media_playback_requires_user_gesture (settings, !NILP (val));
+ else if (EQ (key, Qwebkit_zoom_text_only))
+ webkit_settings_set_zoom_text_only (settings, !NILP (val));
+ else
+ signal_error ("Invalid webkit setting", key);
+ i++;
+ }
+
+ webkit_web_view_set_settings (WEBKIT_WEB_VIEW (xw->widget_osr), settings);
+ return Qnil;
+}
+
+
DEFUN ("xwidget-resize", Fxwidget_resize, Sxwidget_resize, 3, 3, 0,
doc: /* Resize XWIDGET. NEW_WIDTH, NEW_HEIGHT define the new size. */ )
(Lisp_Object xwidget, Lisp_Object new_width, Lisp_Object new_height)
@@ -999,8 +1077,32 @@ syms_of_xwidget (void)
defsubr (&Sxwidget_webkit_get_uri);
defsubr (&Sxwidget_webkit_zoom);
defsubr (&Sxwidget_webkit_execute_script);
+ defsubr (&Sxwidget_webkit_set_settings);
DEFSYM (Qwebkit, "webkit");
+ /* Symbols used for Webkit view settings */
+ DEFSYM (Qwebkit_allow_file_access_from_file_urls, "webkit-allow-file-access-from-file-urls");
+ DEFSYM (Qwebkit_allow_modal_dialogs, "webkit-allow-modal-dialogs");
+ DEFSYM (Qwebkit_allow_universal_access_from_file_urls, "webkit-allow-universal-access-from-file-urls");
+ DEFSYM (Qwebkit_auto_load_images, "webkit-auto-load-images");
+ DEFSYM (Qwebkit_draw_compositing_indicators, "webkit-draw-compositing-indicators");
+ DEFSYM (Qwebkit_enable_accelerated_2d_canvas, "webkit-enable-accelerated-2d-canvas");
+ DEFSYM (Qwebkit_enable_caret_browsing, "webkit-enable-caret-browsing");
+ DEFSYM (Qwebkit_enable_developer_extras, "webkit-enable-developer-extras");
+ DEFSYM (Qwebkit_enable_dns_prefetching, "webkit-enable-dns-prefetching");
+ DEFSYM (Qwebkit_enable_frame_flattening, "webkit-enable-frame-flattening");
+ DEFSYM (Qwebkit_enable_javascript, "webkit-enable-javascript");
+ DEFSYM (Qwebkit_enable_private_browsing, "webkit-enable-private-browsing");
+ DEFSYM (Qwebkit_enable_webaudio, "webkit-enable-webaudio");
+ DEFSYM (Qwebkit_enable_webgl, "webkit-enable-webgl");
+ DEFSYM (Qwebkit_enable_write_console_messages_to_stdout, "webkit-enable-write-console-messages-to-stdout");
+ DEFSYM (Qwebkit_enable_xss_auditor, "webkit-enable-xss-auditor");
+ DEFSYM (Qwebkit_javascript_can_access_clipboard, "webkit-javascript-can-access-clipboard");
+ DEFSYM (Qwebkit_javascript_can_open_windows_automatically, "webkit-javascript-can-open-windows-automatically");
+ DEFSYM (Qwebkit_load_icons_ignoring_image_load_setting, "webkit-load-icons-ignoring-image-load-setting");
+ DEFSYM (Qwebkit_media_playback_requires_user_gesture, "webkit-media-playback-requires-user-gesture");
+ DEFSYM (Qwebkit_zoom_text_only, "webkit-zoom-text-only");
+
defsubr (&Sxwidget_size_request);
defsubr (&Sdelete_xwidget_view);
[-- Attachment #3: Type: text/plain, Size: 12 bytes --]
--
Ricardo
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: fine grained control of webkit browsing
2018-06-19 16:19 ` Ricardo Wurmus
@ 2018-06-19 16:37 ` Perry E. Metzger
2018-06-19 18:58 ` joakim
2018-06-20 0:19 ` T.V Raman
2018-06-19 22:57 ` Richard Stallman
1 sibling, 2 replies; 11+ messages in thread
From: Perry E. Metzger @ 2018-06-19 16:37 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: emacs-devel
On Tue, 19 Jun 2018 18:19:07 +0200 Ricardo Wurmus
<rekado@elephly.net> wrote:
> Perry E. Metzger <perry@piermont.com> writes:
>
> > 2) Say one wants to do things like viewing something with
> > javascript off and without loading remote elements (say because
> > one wants to safely view some HTML email). What does one need to
> > do to get this to work?
>
> The widget is not fully integrated into Emacs.
It would be neat if it were. One would like, for example,
to be able to move a cursor around in it with keyboard commands,
copy text, and move back to another buffer and paste it without
touching the mouse.
> The extent to which one can conveniently communicate with the widget
> is by sending a string containing a JavaScript program to the widget
> and have it return a value. Everything else requires exposing
> Webkit API features to Elisp.
Ah, so at the moment, this isn't yet at the point where (for example)
one could safely use it to view HTML email. (To do that, among other
things, one needs to shut off JavaScript and to allow programmatic
control over which images are loaded.)
> Attached is an old patch that I never submitted that allows one to
> set webkit settings via Elisp. Unfortunately, disabling JavaScript
> for the widget also disables JavaScript evaluation of strings that
> are sent from Emacs -- we use JavaScript for telling the widget to
> scroll, for example. (See ___xwidget-webkit-scroll-bottom___ or
> ___xwidget-webkit-show-element___.)
So it would be necessary to tighten the integration a lot more in
order to make this work as cleanly as one might like?
Perry
--
Perry E. Metzger perry@piermont.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: fine grained control of webkit browsing
2018-06-19 16:37 ` Perry E. Metzger
@ 2018-06-19 18:58 ` joakim
2018-06-19 20:51 ` Perry E. Metzger
2018-06-20 0:19 ` T.V Raman
1 sibling, 1 reply; 11+ messages in thread
From: joakim @ 2018-06-19 18:58 UTC (permalink / raw)
To: Perry E. Metzger; +Cc: Ricardo Wurmus, emacs-devel
"Perry E. Metzger" <perry@piermont.com> writes:
> On Tue, 19 Jun 2018 18:19:07 +0200 Ricardo Wurmus
> <rekado@elephly.net> wrote:
>> Perry E. Metzger <perry@piermont.com> writes:
>>
>> > 2) Say one wants to do things like viewing something with
>> > javascript off and without loading remote elements (say because
>> > one wants to safely view some HTML email). What does one need to
>> > do to get this to work?
>>
>> The widget is not fully integrated into Emacs.
>
> It would be neat if it were. One would like, for example,
> to be able to move a cursor around in it with keyboard commands,
> copy text, and move back to another buffer and paste it without
> touching the mouse.
>
>> The extent to which one can conveniently communicate with the widget
>> is by sending a string containing a JavaScript program to the widget
>> and have it return a value. Everything else requires exposing
>> Webkit API features to Elisp.
>
> Ah, so at the moment, this isn't yet at the point where (for example)
> one could safely use it to view HTML email. (To do that, among other
> things, one needs to shut off JavaScript and to allow programmatic
> control over which images are loaded.)
>
>> Attached is an old patch that I never submitted that allows one to
>> set webkit settings via Elisp. Unfortunately, disabling JavaScript
>> for the widget also disables JavaScript evaluation of strings that
>> are sent from Emacs -- we use JavaScript for telling the widget to
>> scroll, for example. (See ___xwidget-webkit-scroll-bottom___ or
>> ___xwidget-webkit-show-element___.)
>
> So it would be necessary to tighten the integration a lot more in
> order to make this work as cleanly as one might like?
The original idea was to expose the entire webkit api to emacs using
gobject introspection. There is an initial attempt to do this in one of
the xwidget branches. That work is stalled. I think it would be a
nice project for some enterprising person though.
>
> Perry
--
Joakim Verona
joakim@verona.se
+46705459454
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: fine grained control of webkit browsing
2018-06-19 18:58 ` joakim
@ 2018-06-19 20:51 ` Perry E. Metzger
2018-06-19 21:31 ` joakim
0 siblings, 1 reply; 11+ messages in thread
From: Perry E. Metzger @ 2018-06-19 20:51 UTC (permalink / raw)
To: joakim; +Cc: Ricardo Wurmus, emacs-devel
On Tue, 19 Jun 2018 20:58:09 +0200 joakim@verona.se wrote:
> The original idea was to expose the entire webkit api to emacs using
> gobject introspection. There is an initial attempt to do this in
> one of the xwidget branches. That work is stalled. I think it would
> be a nice project for some enterprising person though.
Where is the branch located?
--
Perry E. Metzger perry@piermont.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: fine grained control of webkit browsing
2018-06-19 20:51 ` Perry E. Metzger
@ 2018-06-19 21:31 ` joakim
0 siblings, 0 replies; 11+ messages in thread
From: joakim @ 2018-06-19 21:31 UTC (permalink / raw)
To: Perry E. Metzger; +Cc: Ricardo Wurmus, emacs-devel
"Perry E. Metzger" <perry@piermont.com> writes:
> On Tue, 19 Jun 2018 20:58:09 +0200 joakim@verona.se wrote:
>> The original idea was to expose the entire webkit api to emacs using
>> gobject introspection. There is an initial attempt to do this in
>> one of the xwidget branches. That work is stalled. I think it would
>> be a nice project for some enterprising person though.
>
> Where is the branch located?
http://git.savannah.gnu.org/cgit/emacs.git/log/?h=xwidget
Xwidget was the original branch that was later stripped down to
xwidget_mvp. xwidget_mvp was the branch that was merged into master.
Xwidget had some other widgets besides the webkit one, and also
embryonic gobject introspection support.
--
Joakim Verona
joakim@verona.se
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: fine grained control of webkit browsing
2018-06-19 16:19 ` Ricardo Wurmus
2018-06-19 16:37 ` Perry E. Metzger
@ 2018-06-19 22:57 ` Richard Stallman
2018-06-20 1:20 ` Perry E. Metzger
1 sibling, 1 reply; 11+ messages in thread
From: Richard Stallman @ 2018-06-19 22:57 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: emacs-devel, perry
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> The widget is not fully integrated into Emacs. The extent to which one
> can conveniently communicate with the widget is by sending a string
> containing a JavaScript program to the widget and have it return a
> value.
In what computer does that JavaScript program get executed?
Why use JavaScript here?
--
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: fine grained control of webkit browsing
2018-06-19 16:37 ` Perry E. Metzger
2018-06-19 18:58 ` joakim
@ 2018-06-20 0:19 ` T.V Raman
1 sibling, 0 replies; 11+ messages in thread
From: T.V Raman @ 2018-06-20 0:19 UTC (permalink / raw)
To: Perry E. Metzger; +Cc: Ricardo Wurmus, emacs-devel
Another possible way of communicating with the browser might be via
the debugger API e.g. port 9222 on Chrome. Package indium already lets
you do a lot of this and using that as the integration mechanism might
feel fairly seamless.
--
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: fine grained control of webkit browsing
2018-06-19 22:57 ` Richard Stallman
@ 2018-06-20 1:20 ` Perry E. Metzger
2018-06-20 23:26 ` Richard Stallman
0 siblings, 1 reply; 11+ messages in thread
From: Perry E. Metzger @ 2018-06-20 1:20 UTC (permalink / raw)
To: Richard Stallman; +Cc: Ricardo Wurmus, emacs-devel
On Tue, 19 Jun 2018 18:57:08 -0400 Richard Stallman <rms@gnu.org>
wrote:
> > The widget is not fully integrated into Emacs. The extent to
> > which one can conveniently communicate with the widget is by
> > sending a string containing a JavaScript program to the widget
> > and have it return a value.
>
> In what computer does that JavaScript program get executed?
Inside the same Emacs process on the same machine. WebKit is linked
in to Emacs and controls a window. JavaScript is being injected by
elisp into the WebKit instance to control it.
> Why use JavaScript here?
In the absence of having the full WebKit API exposed to the rest of
Emacs, it's the only obvious way to tell WebKit to do things like
scrolling the window. Yes, it's not really what you want, which is
what we are discussing. Ideally, the entirety of the WebKit API would
be exposed to the elisp layer and one could much more tightly
integrate the browser into the rest of the editor.
Perry
--
Perry E. Metzger perry@piermont.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: fine grained control of webkit browsing
2018-06-20 1:20 ` Perry E. Metzger
@ 2018-06-20 23:26 ` Richard Stallman
2018-06-21 0:00 ` Perry E. Metzger
0 siblings, 1 reply; 11+ messages in thread
From: Richard Stallman @ 2018-06-20 23:26 UTC (permalink / raw)
To: Perry E. Metzger; +Cc: rekado, emacs-devel
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > In what computer does that JavaScript program get executed?
> Inside the same Emacs process on the same machine. WebKit is linked
> in to Emacs and controls a window. JavaScript is being injected by
> elisp into the WebKit instance to control it.
> > Why use JavaScript here?
Now that I see the architecture, I conclude that using JavaScript this way
is not an ethical problem. It's free code in a program the user installs, so
ethically it's as good as any other free code in a program the user installs.
We could perhaps expose the interface to Lisp by defining Lisp functions
that work by sending JavaScript code. Somewhat inelegant in implementation,
but that might not matter to Lisp programs that use these functions.
--
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: fine grained control of webkit browsing
2018-06-20 23:26 ` Richard Stallman
@ 2018-06-21 0:00 ` Perry E. Metzger
0 siblings, 0 replies; 11+ messages in thread
From: Perry E. Metzger @ 2018-06-21 0:00 UTC (permalink / raw)
To: Richard Stallman; +Cc: rekado, emacs-devel
On Wed, 20 Jun 2018 19:26:40 -0400 Richard Stallman <rms@gnu.org>
wrote:
> Now that I see the architecture, I conclude that using JavaScript
> this way is not an ethical problem. It's free code in a program
> the user installs, so ethically it's as good as any other free code
> in a program the user installs.
>
> We could perhaps expose the interface to Lisp by defining Lisp
> functions that work by sending JavaScript code. Somewhat inelegant
> in implementation, but that might not matter to Lisp programs that
> use these functions.
The superior method is to expose the C/C++ API to WebKit to elisp.
However, no one has yet done the work to make this happen.
We do not want to use the JavaScript method you suggest long term
because system safety requires that JavaScript be turned off when
browsing certain content, such as email. If we depend on JavaScript
under such circumstances, we will cease to be able to control the
window and view untrusted content safely at the same time.
For the moment, however, it works okayish.
Perry
--
Perry E. Metzger perry@piermont.com
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-06-21 0:00 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-06-19 15:49 fine grained control of webkit browsing Perry E. Metzger
2018-06-19 16:19 ` Ricardo Wurmus
2018-06-19 16:37 ` Perry E. Metzger
2018-06-19 18:58 ` joakim
2018-06-19 20:51 ` Perry E. Metzger
2018-06-19 21:31 ` joakim
2018-06-20 0:19 ` T.V Raman
2018-06-19 22:57 ` Richard Stallman
2018-06-20 1:20 ` Perry E. Metzger
2018-06-20 23:26 ` Richard Stallman
2018-06-21 0:00 ` Perry E. Metzger
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).