Discussion:
bug#21650: 24.5; mh-e keeps trying to open urls
Bill Wohler
2016-01-10 20:38:19 UTC
Permalink
[Redirected to mh-e-devel.]
In generally, I'd expect to see some option in MH-E to disable this.
I'm working on adding a user-visible control for use with shr: never
display images, only display local images (i.e., ones that are included
with the email), or display all (local and remote) images.
Thanks, Mike. Are you making the changes in the Gnus or shr library, or
MH-E?
MH-E doesn't render HTML directly, so the options would be in the gnus
(and below) libraries.
It should be possible to inhibit all image display by setting
gnus-inhibit-images to a non-nil value. See
http://sourceforge.net/p/mh-e/bugs/478/ for further discussion.
Another workaround would be to change mm-text-html-renderer (e.g., set
it to 'w3m-standalone).
mike
--
Bill Wohler <***@newt.com> aka <***@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD
Mike Kupfer
2016-01-11 02:29:36 UTC
Permalink
Post by Bill Wohler
I'm working on adding a user-visible control for use with shr: never
display images, only display local images (i.e., ones that are included
with the email), or display all (local and remote) images.
Thanks, Mike. Are you making the changes in the Gnus or shr library, or
MH-E?
The changes are in MH-E. There isn't a clean separation between shr and
Gnus, so in my patch, MH-E rebinds two Gnus control variables to force
the user-specified behavior. Below is a partial "diff -b" patch that
has the main logic.

I've got the basic functionality working, and right now I'm working on
integrating with Customize. After that I'm planning to update the
documentation and then submit a patch for review. But any comments at
this point are welcome, too.

mike

diff --git a/lisp/mh-e/mh-mime.el b/lisp/mh-e/mh-mime.el
--- a/lisp/mh-e/mh-mime.el
+++ b/lisp/mh-e/mh-mime.el
@@ -709,7 +712,26 @@
region buffer-read-only)
(save-excursion
(unwind-protect
- (let ((win (get-buffer-window (current-buffer) t)))
+ (let ((win (get-buffer-window (current-buffer) t))
+ inhibit-images blocked-images)
+ (cond
+ ((eq mh-show-html-images 'attached)
+ (setq inhibit-images nil)
+ (setq blocked-images "."))
+ ((eq mh-show-html-images 'all)
+ (setq inhibit-images nil)
+ (setq blocked-images nil))
+ ((null mh-show-html-images)
+ (setq inhibit-images t)
+ (setq blocked-images "."))
+ (t
+ (warn "mh-show-html-images: unrecognized value: %s"
+ mh-show-html-images)
+ (setq inhibit-images gnus-inhibit-images)
+ (setq blocked-images gnus-blocked-images)))
+
+ (let ((gnus-blocked-images blocked-images)
+ (gnus-inhibit-images inhibit-images))
(when win
(select-window win))
(goto-char point)
@@ -761,7 +783,7 @@
(when region
(add-text-properties (mh-line-beginning-position)
(mh-line-end-position)
- `(mh-region ,region)))))))
+ `(mh-region ,region))))))))

(defun mh-mime-part-index (handle)
"Generate the button number for MIME part, HANDLE.
Bill Wohler
2016-01-11 02:46:08 UTC
Permalink
Post by Mike Kupfer
Post by Bill Wohler
I'm working on adding a user-visible control for use with shr: never
display images, only display local images (i.e., ones that are included
with the email), or display all (local and remote) images.
Thanks, Mike. Are you making the changes in the Gnus or shr library, or
MH-E?
The changes are in MH-E. There isn't a clean separation between shr and
Gnus, so in my patch, MH-E rebinds two Gnus control variables to force
the user-specified behavior. Below is a partial "diff -b" patch that
has the main logic.
I'd be reluctant to make the change in MH-E since it would be an ongoing
maintenance problem. Such an option should be renderer agnostic and the
documentation should list the renderers that support it. This would have
to be maintained.

It seems that the user should be setting gnus-blocked-images and
gnus-inhibit-images, not us. For example, there isn't an MH-E option
called mh-inline-large-images; the user sets mm-inline-large-images
directly, if they want. However, is there already a precedent for
providing an MH-E option for an option in an underlying library?

If we do add this code to MH-E, I'd suggest making the new option very
similar to that of mh-fetch-x-image-url; that is, it has the values Ask
Before Fetching, and Never Fetch. The issue is the fetching of URLs, not
the display of images. Thus, I wouldn't bother with "not displaying
included images."

Still, I don't think MH-E is the right place for any of this. We simply
call mm-inline-text-html-renderer. Any configuration of how this is done
should be at the level of mm-inline-text-html-renderer.

Note that in http://mh-e.sourceforge.net/manual/html/HTML.html#HTML, we
already say, "See the documentation for the browser you use for
additional information on how to use it. In particular, find and disable
the option to render images as this can tip off spammers that the email
address they have used is valid."
Post by Mike Kupfer
I've got the basic functionality working, and right now I'm working on
integrating with Customize. After that I'm planning to update the
documentation and then submit a patch for review. But any comments at
this point are welcome, too.
mike
diff --git a/lisp/mh-e/mh-mime.el b/lisp/mh-e/mh-mime.el
--- a/lisp/mh-e/mh-mime.el
+++ b/lisp/mh-e/mh-mime.el
@@ -709,7 +712,26 @@
region buffer-read-only)
(save-excursion
(unwind-protect
- (let ((win (get-buffer-window (current-buffer) t)))
+ (let ((win (get-buffer-window (current-buffer) t))
+ inhibit-images blocked-images)
+ (cond
+ ((eq mh-show-html-images 'attached)
+ (setq inhibit-images nil)
+ (setq blocked-images "."))
+ ((eq mh-show-html-images 'all)
+ (setq inhibit-images nil)
+ (setq blocked-images nil))
+ ((null mh-show-html-images)
+ (setq inhibit-images t)
+ (setq blocked-images "."))
+ (t
+ (warn "mh-show-html-images: unrecognized value: %s"
+ mh-show-html-images)
+ (setq inhibit-images gnus-inhibit-images)
+ (setq blocked-images gnus-blocked-images)))
+
+ (let ((gnus-blocked-images blocked-images)
+ (gnus-inhibit-images inhibit-images))
(when win
(select-window win))
(goto-char point)
@@ -761,7 +783,7 @@
(when region
(add-text-properties (mh-line-beginning-position)
(mh-line-end-position)
- `(mh-region ,region)))))))
+ `(mh-region ,region))))))))
(defun mh-mime-part-index (handle)
"Generate the button number for MIME part, HANDLE.
--
Bill Wohler <***@newt.com> aka <***@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD
Mike Kupfer
2016-01-11 05:33:34 UTC
Permalink
Post by Bill Wohler
I'd be reluctant to make the change in MH-E since it would be an ongoing
maintenance problem. Such an option should be renderer agnostic and the
documentation should list the renderers that support it. This would have
to be maintained.
In terms of design principles I agree.

The reason I went with this approach was that I couldn't see a cleaner
way to get the functionality that I want.

As for being renderer-agnostic, I'm not aware of any renderers besides
shr that display images. But that's sort of beside the point--you'll
notice that the patch doesn't set any shr variables, just gnus
variables.

The reason this is so inelegant is the way Gnus and shr are tied
together.

- mm-shr calls #'gnus-blocked-images to get the regexp for
images.
- This turns into a call to #'gnus-block-private-groups, which
returns nil if reading a newsgroup and "." for anything else.
- #'gnus-block-private-groups only works right if called from
Gnus: it calls #'gnus-news-group-p and #'gnus-member-of-valid to
determine what you're reading.

So, yes, the user could just set gnus-inhibit-images if they never want
images. I tried that, and I found that it blocked images that I wanted
to see. That means having to deal with gnus-blocked-images.

I suppose we could tell the user to write their own function to replace
gnus-block-private-groups. That doesn't strike me as user-friendly,
particularly if the user wants the function to work for both MH-E and
Gnus.

We could provide an family of functions to supplement
gnus-block-private-groups and add them to the choice list for
gnus-blocked-images. But that requires buy-in from the Gnus folks, it
is arguably less clean than my patch (because the Gnus code would know
who its callers are), and it still doesn't solve the technical hurdles
related to working correctly for both MH-E and Gnus.
Post by Bill Wohler
If we do add this code to MH-E, I'd suggest making the new option very
similar to that of mh-fetch-x-image-url; that is, it has the values Ask
Before Fetching, and Never Fetch. The issue is the fetching of URLs, not
the display of images. Thus, I wouldn't bother with "not displaying
included images."
That's a fair point. I'd certainly be willing to rework my patch to use
that approach.
Post by Bill Wohler
Still, I don't think MH-E is the right place for any of this. We simply
call mm-inline-text-html-renderer. Any configuration of how this is done
should be at the level of mm-inline-text-html-renderer.
Well, there's a variable mm-inline-text-html-with-images which, based on
the documentation, would seem to be all the user needs.

mm-inline-text-html-with-images is a variable defined in `mm-decode.el'.
Its value is nil

Documentation:
If non-nil, Gnus will allow retrieving images in HTML contents with
the <img> tags. It has no effect on Emacs/w3. See also the
documentation for the `mm-w3m-safe-url-regexp' variable.

(There's so much layering in this part of the code, I didn't realize
this variable existed until I just now did an apropos search on
mm.*html.) But it doesn't work. It's set to nil, and I can still see
remotely-stored images.

I'll see if I can figure out why mm-inline-text-html-with-images doesn't
work. Maybe all that's needed is a simple bugfix in that part of the
code. But if disallowing the display of remote images also breaks the
display of images that are embedded in the mail, that will be inadequate
for my purposes. Solving this cleanly could take awhile.

mike
Mike Kupfer
2016-01-19 00:11:18 UTC
Permalink
Post by Mike Kupfer
Post by Bill Wohler
Still, I don't think MH-E is the right place for any of this. We simply
call mm-inline-text-html-renderer. Any configuration of how this is done
should be at the level of mm-inline-text-html-renderer.
Well, there's a variable mm-inline-text-html-with-images which, based on
the documentation, would seem to be all the user needs.
mm-inline-text-html-with-images is a variable defined in `mm-decode.el'.
Its value is nil
If non-nil, Gnus will allow retrieving images in HTML contents with
the <img> tags. It has no effect on Emacs/w3. See also the
documentation for the `mm-w3m-safe-url-regexp' variable.
[...]
Post by Mike Kupfer
But it doesn't work. It's set to nil, and I can still see
remotely-stored images.
I'll see if I can figure out why mm-inline-text-html-with-images doesn't
work.
AFAICT, it's just not used except for w3m.

Trying to fix this at the mm layer looks messy, because there are now 2
competing sets of control variables (this one and gnus-blocked-images).
But I can ask about it on ding.

The problem can be "fixed" at the MH-E level without adding a new
configuration variable; see diffs to mh-mm-display-part below. There's
still some work to do here--when I enable fetching of remote images, the
show buffer gets marked as modified, so I get an annoying prompt when I
display a different message. But I think that problem is orthogonal to
how we control the fetching/display of images.

mike

diff --git a/lisp/mh-e/mh-mime.el b/lisp/mh-e/mh-mime.el
--- a/lisp/mh-e/mh-mime.el
+++ b/lisp/mh-e/mh-mime.el
@@ -709,7 +709,9 @@
region buffer-read-only)
(save-excursion
(unwind-protect
- (let ((win (get-buffer-window (current-buffer) t)))
+ (let ((win (get-buffer-window (current-buffer) t))
+ (gnus-blocked-images
+ (if mm-inline-text-html-with-images nil ".")))
(when win
(select-window win))
(goto-char point)
Mike Kupfer
2016-02-01 03:48:42 UTC
Permalink
Post by Mike Kupfer
Trying to fix this at the mm layer looks messy, because there are now 2
competing sets of control variables (this one and gnus-blocked-images).
But I can ask about it on ding.
I posted a question about this on ding on Thursday (January 28th);
haven't gotten any responses yet.

After I sent the ding email, it occurred to me that a reasonably clean
fix might be possible. If I understand the code correctly, this would
require changes to mm-decode.el (change mm-shr to use
mm-inline-text-html-with-images instead of gnus-blocked-images), plus
changes to Gnus to set mm-inline-text-html-with-images based on
gnus-blocked-images.

Without some buy-in from the Gnus developers, though, I'd like to
proceed with the patch below, to get this issue off the stopper list for
25.1.
Post by Mike Kupfer
diff --git a/lisp/mh-e/mh-mime.el b/lisp/mh-e/mh-mime.el
--- a/lisp/mh-e/mh-mime.el
+++ b/lisp/mh-e/mh-mime.el
@@ -709,7 +709,9 @@
region buffer-read-only)
(save-excursion
(unwind-protect
- (let ((win (get-buffer-window (current-buffer) t)))
+ (let ((win (get-buffer-window (current-buffer) t))
+ (gnus-blocked-images
+ (if mm-inline-text-html-with-images nil ".")))
(when win
(select-window win))
(goto-char point)
What do you think?

mike
Bill Wohler
2016-02-01 05:34:05 UTC
Permalink
I'm not comfortable seeing any patch for this in MH-E, no matter how
small.

My concern is that this only works with shr and not with all of the
other renderers we support. Indeed, the documentation for
mm-inline-text-html-with-images says:

If non-nil, Gnus will allow retrieving images in HTML contents with
the <img> tags. It has no effect on Emacs/w3. See also the
documentation for the `mm-w3m-safe-url-regexp' variable.

I use w3, so this patch would have no effect for me.

Let's assign this issue to the renderer that the original poster had
issues with, which is shr, right? I think that's a better resolution
from the MH-E perspective. Don't you think?
Post by Mike Kupfer
Post by Mike Kupfer
Trying to fix this at the mm layer looks messy, because there are now 2
competing sets of control variables (this one and gnus-blocked-images).
But I can ask about it on ding.
I posted a question about this on ding on Thursday (January 28th);
haven't gotten any responses yet.
After I sent the ding email, it occurred to me that a reasonably clean
fix might be possible. If I understand the code correctly, this would
require changes to mm-decode.el (change mm-shr to use
mm-inline-text-html-with-images instead of gnus-blocked-images), plus
changes to Gnus to set mm-inline-text-html-with-images based on
gnus-blocked-images.
Without some buy-in from the Gnus developers, though, I'd like to
proceed with the patch below, to get this issue off the stopper list for
25.1.
Post by Mike Kupfer
diff --git a/lisp/mh-e/mh-mime.el b/lisp/mh-e/mh-mime.el
--- a/lisp/mh-e/mh-mime.el
+++ b/lisp/mh-e/mh-mime.el
@@ -709,7 +709,9 @@
region buffer-read-only)
(save-excursion
(unwind-protect
- (let ((win (get-buffer-window (current-buffer) t)))
+ (let ((win (get-buffer-window (current-buffer) t))
+ (gnus-blocked-images
+ (if mm-inline-text-html-with-images nil ".")))
(when win
(select-window win))
(goto-char point)
What do you think?
mike
--
Bill Wohler <***@newt.com> aka <***@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD
Mike Kupfer
2016-02-01 14:53:47 UTC
Permalink
Post by Bill Wohler
Let's assign this issue to the renderer that the original poster had
issues with, which is shr, right?
I'll add a note to the Emacs bug (21650) that details what I've found.
That's all the reassignment that's possible with the current debbugs
setup AFAICT.

If you really want, I can close SF#478, probably "wont-fix" rather than
"invalid".
Post by Bill Wohler
I think that's a better resolution
from the MH-E perspective. Don't you think?
If it actually gets fixed, yes. I'm not holding my breath.

mike
Bill Wohler
2016-02-01 15:26:36 UTC
Permalink
Post by Mike Kupfer
Post by Bill Wohler
Let's assign this issue to the renderer that the original poster had
issues with, which is shr, right?
I'll add a note to the Emacs bug (21650) that details what I've found.
That's all the reassignment that's possible with the current debbugs
setup AFAICT.
I'll look into this as I'm not familiar with debbugs either (other than
as a user). Perhaps Peter can give us a hint.
Post by Mike Kupfer
If you really want, I can close SF#478, probably "wont-fix" rather than
"invalid".
Let's see if we can reassign it first. I'll look into that tonight.
Post by Mike Kupfer
Post by Bill Wohler
I think that's a better resolution
from the MH-E perspective. Don't you think?
If it actually gets fixed, yes. I'm not holding my breath.
mike
--
Bill Wohler <***@newt.com> aka <***@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD
Mike Kupfer
2016-02-01 18:07:19 UTC
Permalink
Post by Bill Wohler
Post by Mike Kupfer
I'll add a note to the Emacs bug (21650) that details what I've found.
That's all the reassignment that's possible with the current debbugs
setup AFAICT.
I'll look into this as I'm not familiar with debbugs either (other than
as a user). Perhaps Peter can give us a hint.
Reassigning is pretty straightforward (see
http://debbugs.gnu.org/server-control.html). I just reassigned #22157
yesterday from "gnus" to "emacs" using
http://debbugs.gnu.org/cgi/bugreport.cgi?msg=7;bug=22157. (Contrary to
the documentation, though, I wasn't able to change the version number.)

The question is, what package do you reassign it to. The "gnus" package
doesn't seem to get much attention from the Gnus developers. The
commentary on ding was to either report problems via direct email to
ding, or by filing a bug against the "emacs" package.

Hmm. I see that Glenn Morris has assigned #22157 to "emacs,gnus".
Maybe that's the thing to do for 21650, too.
Post by Bill Wohler
Post by Mike Kupfer
If you really want, I can close SF#478, probably "wont-fix" rather than
"invalid".
Let's see if we can reassign it first. I'll look into that tonight.
I was assuming that SourceForge would only let you reassign issues to
other SourceForge projects. (And that's further assuming you can even
reassign issues to a different project at all.) But let me know what
you find out.

thanks,
mike
Bill Wohler
2016-02-01 21:54:46 UTC
Permalink
Post by Mike Kupfer
Post by Bill Wohler
Post by Mike Kupfer
I'll add a note to the Emacs bug (21650) that details what I've found.
That's all the reassignment that's possible with the current debbugs
setup AFAICT.
I'll look into this as I'm not familiar with debbugs either (other than
as a user). Perhaps Peter can give us a hint.
Reassigning is pretty straightforward (see
http://debbugs.gnu.org/server-control.html). I just reassigned #22157
yesterday from "gnus" to "emacs" using
http://debbugs.gnu.org/cgi/bugreport.cgi?msg=7;bug=22157. (Contrary to
the documentation, though, I wasn't able to change the version number.)
The question is, what package do you reassign it to. The "gnus" package
doesn't seem to get much attention from the Gnus developers. The
commentary on ding was to either report problems via direct email to
ding, or by filing a bug against the "emacs" package.
Hmm. I see that Glenn Morris has assigned #22157 to "emacs,gnus".
Maybe that's the thing to do for 21650, too.
Sounds good, thanks!
Post by Mike Kupfer
Post by Bill Wohler
Post by Mike Kupfer
If you really want, I can close SF#478, probably "wont-fix" rather than
"invalid".
Let's see if we can reassign it first. I'll look into that tonight.
I was assuming that SourceForge would only let you reassign issues to
other SourceForge projects. (And that's further assuming you can even
reassign issues to a different project at all.) But let me know what
you find out.
I really shouldn't reply when running out the door to catch a train :-).
I had missed that you were addressing the SourceForge issue rather than
the Emacs issue. Yes, of course, what you propose is perfect!
Post by Mike Kupfer
thanks,
mike
Thank you!
--
Bill Wohler <***@newt.com> aka <***@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD
Continue reading on narkive:
Search results for 'bug#21650: 24.5; mh-e keeps trying to open urls' (Questions and Answers)
223
replies
Is someone watching me through my computer?
started 2015-02-15 03:59:11 UTC
security
Loading...