From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "Perry E. Metzger" Newsgroups: gmane.emacs.devel Subject: Re: fine grained control of webkit browsing Date: Tue, 19 Jun 2018 12:37:16 -0400 Message-ID: <20180619123716.5741c9c0@jabberwock.cb.piermont.com> References: <20180619114906.4437a1f6@jabberwock.cb.piermont.com> <87po0mvjes.fsf@elephly.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1529426470 5821 195.159.176.226 (19 Jun 2018 16:41:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 19 Jun 2018 16:41:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ricardo Wurmus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 19 18:41:05 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fVJgl-0001OO-Lg for ged-emacs-devel@m.gmane.org; Tue, 19 Jun 2018 18:41:03 +0200 Original-Received: from localhost ([::1]:43760 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fVJis-0002ns-J4 for ged-emacs-devel@m.gmane.org; Tue, 19 Jun 2018 12:43:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56556) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fVJdB-0007Wx-Uy for emacs-devel@gnu.org; Tue, 19 Jun 2018 12:37:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fVJd7-0005yt-OH for emacs-devel@gnu.org; Tue, 19 Jun 2018 12:37:21 -0400 Original-Received: from hacklheber.piermont.com ([166.84.7.14]:58308) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fVJd7-0005yh-Hw for emacs-devel@gnu.org; Tue, 19 Jun 2018 12:37:17 -0400 Original-Received: from snark.cb.piermont.com (localhost [127.0.0.1]) by hacklheber.piermont.com (Postfix) with ESMTP id 3B2581AE; Tue, 19 Jun 2018 12:37:17 -0400 (EDT) Original-Received: from jabberwock.cb.piermont.com (jabberwock.cb.piermont.com [10.160.2.107]) by snark.cb.piermont.com (Postfix) with ESMTP id 1FC7E2DEC77; Tue, 19 Jun 2018 12:37:17 -0400 (EDT) In-Reply-To: <87po0mvjes.fsf@elephly.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 166.84.7.14 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:226517 Archived-At: On Tue, 19 Jun 2018 18:19:07 +0200 Ricardo Wurmus wrote: > Perry E. Metzger 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