bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#18334: 24.3.93; ImageMagick: eww shows favicon animations in search


From: YAMAMOTO Mitsuharu
Subject: bug#18334: 24.3.93; ImageMagick: eww shows favicon animations in search results
Date: Sun, 14 Sep 2014 16:42:20 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Wed, 27 Aug 2014 09:57:29 +0900, YAMAMOTO Mitsuharu 
>>>>> <mituharu@math.s.chiba-u.ac.jp> said:

> Steps to Reproduce:
> 1. Build Emacs with the ImageMagick support.

> 2. $ emacs -Q &

> 3. M-x eww RET wikipedia RET

> Result:

> Probably you'll observe animated favicons in the search results by
> DuckDuckGo.  I think these animations are unexpected and unwanted.
> See also bug#18333.

Currently, all the image data containing multiple image frames seems
to be treated as animations.

In shr-put-image (lisp/net/shr.el), we have

          (when (and shr-image-animate
                     (cond ((fboundp 'image-multi-frame-p)
                       ;; Only animate multi-frame things that specify a
                       ;; delay; eg animated gifs as opposed to
                       ;; multi-page tiffs.  FIXME?
                            (cdr (image-multi-frame-p image)))
                           ((fboundp 'image-animated-p)
                            (image-animated-p image))))
            (image-animate image nil 60)))

And in lisp/image.el,

(defun image-multi-frame-p (image)
  "Return non-nil if IMAGE contains more than one frame.
The actual return value is a cons (NIMAGES . DELAY), where NIMAGES is
the number of frames (or sub-images) in the image and DELAY is the delay
in seconds that the image specifies between each frame.  DELAY may be nil,
in which case you might want to use `image-default-frame-delay'."
  (when (fboundp 'image-metadata)
    (let* ((metadata (image-metadata image))
           (images (plist-get metadata 'count))
           (delay (plist-get metadata 'delay)))
      (when (and images (> images 1))
        (if (or (not (numberp delay)) (< delay 0))
            (setq delay image-default-frame-delay))
        (cons images delay)))))

Which should be fixed?  Should image-multi-frame-p, a new function in
24.4, stop using image-default-frame-delay as a default value for
DELAY?  Or should each caller of image-multi-frame-p temporarily
let-bind image-default-frame-delay to nil if it doesn't want to treat
images that are missing DELAY value as animations?

                                     YAMAMOTO Mitsuharu
                                mituharu@math.s.chiba-u.ac.jp





reply via email to

[Prev in Thread] Current Thread [Next in Thread]