Subject: bug#71913: closed (Re: bug#71913: 29.1; shr: shr-resize-image does not behave as expected)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 13 Jul 2024 18:56:01 +0000

Your bug report

#71913: 29.1; shr: shr-resize-image does not behave as expected

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
71913: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71913
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#71913: 29.1; shr: shr-resize-image does not behave as expected
From: Jim Porter <[email-masked]>
To: Eli Zaretskii <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Sat, 13 Jul 2024 11:54:21 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

On 7/13/2024 10:39 AM, Eli Zaretskii wrote:
> Leaving this on master is fine by me, thanks.

Thanks. Closing this bug now, then.

George: we can track this elsewhere since it's not an Emacs bug per se, 
but did you want to submit your Elfeed patch to Elfeed? If you do, let 
me know and I'd be happy to chime in over there to support it getting 
merged.

Subject: 29.1; shr: shr-resize-image does not behave as expected
From: George Huebner <[email-masked]>
To: [email-masked]
Date: Wed, 03 Jul 2024 01:37:52 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

I noticed an issue with =shr-max-image-proportion= wherein images 
would be correctly resized on initial load, but would then appear 
much larger.
I suspected this was an issue with caching, and sure enough, 
either disabling the cache with ~(setq shr-ignore-cache t)~ or 
manually deleting images from the cache results in images 
displaying correctly.
This unanswered 
[[https://www.reddit.com/r/emacs/comments/esa3x5/image_scaling_in_elfeed_entry_window/][Reddit 
post]] seems to corroborate this behaviour.
It looks like it might be because of the codepath taken in 
~shr-tag-img~ wherein a cache miss results in the creation of a 
placeholder image; I had some trouble with edebug though, so 
that's just an educated guess.

Here's a minimal reproducible example (credit to Sacha Chua):
#+begin_src elisp :eval no
;; run this (image is very large), run again many times without 
   killing *test* (image is correct size), kill *test* and run 
   again (image is large again)
;; won't observe this behaviour if you disable cache
;; (setq shr-ignore-cache t)
(setq shr-max-image-proportion 0.5)
(with-current-buffer (get-buffer-create "*test*")
  (erase-buffer)
  (insert "<img 
  src=\"https://upload.wikimedia.org/wikipedia/commons/8/83/The_GNU_logo.png\">")
  (shr-insert-document (libxml-parse-html-region (point-min) 
  (point-max)))
  (display-buffer (current-buffer)))
#+end_src elisp

I also observed this behaviour on Emacs master (667ca66), but I 
daily drive 29.1.
In GNU Emacs 29.1 (build 1, aarch64-apple-darwin23.4.0, Carbon 
Version
170 AppKit 2487.5)
Windowing system distributor 'Apple Inc.', version 14.4.0
System Description:  macOS 14.4

Configured using:
 'configure
 --prefix=/nix/store/ismv7jzf3hcqziq5bpjfs54zd4qfjjn7-emacs-mac-macport-29.1
 --disable-build-details --with-modules --without-gif 
 --without-jpeg
 --without-png --without-tiff --without-x --without-xpm
 '--enable-mac-app=$$out/Applications' --with-gnutls --with-mac
 --with-xml2 --without-ns --with-compress-install
 --with-toolkit-scroll-bars --with-native-compilation
 --without-imagemagick --with-mailutils --without-small-ja-dic
 --with-tree-sitter --without-xinput2 --without-xwidgets 
 --without-dbus
 --without-selinux --with-xwidgets'