User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a3pre) Gecko/20100304 Minefield/3.7a3pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a3pre) Gecko/20100304 Minefield/3.7a3pre The frame count is only displayed for regular images. It is not displayed for background images. Reproducible: Always Steps to Reproduce: 1. Open the testcase 2. Tools -> Page Info -> Media Actual Results: The frame count is only shown for the image, but not for the background image. Expected Results: The frame count should be shown for both.

I see the same thing on Mozilla/5.0 (Windows; U; Windows NT 6.0; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100601 Minefield/3.7a5pre (.NET CLR 3.5.30729) ID:20100601040444

Is this bug still valid? Even for regular images (<img> element) the frame count is not shown anymore. (When was it removed? Was this intentional?) I can neither find a bug to add this information back again nor the bug in which it was removed...

> Is this bug still valid? Yes. > Even for regular images (<img> element) the frame count is not shown anymore. > (When was it removed? Was this intentional?) The image url in the original test case is now 404. Bug can be seen in this updated URL.

Hmm. http://hg.mozilla.org/mozilla-central/rev/e21922aa5d9a http://hg.mozilla.org/mozilla-central/rev/818c6feeb5e9 http://hg.mozilla.org/mozilla-central/rev/a4303a416630 Bug 426029 (Media preview displays broken images for images with data url) excluded background images. No idea why.

> > Even for regular images (<img> element) the frame count is not shown anymore. > > (When was it removed? Was this intentional?) > The image url in the original test case is now 404. Yes, I know but... > Bug can be seen in this updated URL. ...at least for me (on WinXP) the frame count is not shown for the background image, but it also is _NOT_ shown for the regular image.

In Firefox 3.6.11 the frame count is still shown for the regular image. (And in 3.7a3pre, when I reported this bug, obviously as well, else I wouldn't have reported this bug...)

But in Firefox 4.0.1 the frame count for regular images is missing.

CC Dão in case he has some ideas.

(In reply to Philip Chee from comment #5) > Hmm. > > http://hg.mozilla.org/mozilla-central/rev/e21922aa5d9a > http://hg.mozilla.org/mozilla-central/rev/818c6feeb5e9 > http://hg.mozilla.org/mozilla-central/rev/a4303a416630 What are these? Regression ranges?

> What are these? Regression ranges? No just looking at Hg blame around the code that counts frames.

Regression window for _NOT_ shown for the regular image: Works; http://hg.mozilla.org/mozilla-central/rev/6281bc7f1bbf Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100813 Minefield/4.0b4pre ID:20100813205257 Fails: http://hg.mozilla.org/mozilla-central/rev/17f4064c1d23 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100813 Minefield/4.0b4pre ID:20100813230431 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6281bc7f1bbf&tochange=17f4064c1d23 Suspecred: Bug 584841

(In reply to Alice0775 White from comment #12) > Regression window for _NOT_ shown for the regular image: > Works; > http://hg.mozilla.org/mozilla-central/rev/6281bc7f1bbf > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100813 > Minefield/4.0b4pre ID:20100813205257 I'm confused -- this bug was filed on 2010-03-06 (date on Comment 0), but the bug didn't appear until 5 months later?

...or is that regression range for a slightly different bug? (for comment 8?) It seems like it'd be best to file a new bug on comment 8 & beyond, and leave this bug to track the original issue, to avoid confusion/mixup like comment 13.

(In reply to Daniel Holbert [:dholbert] from comment #14) > ...or is that regression range for a slightly different bug? (for comment 8?) > > It seems like it'd be best to file a new bug on comment 8 & beyond, and > leave this bug to track the original issue, to avoid confusion/mixup like > comment 13. filed Bug 713889

oops sorry

I think this bug's status should have stayed NEW. (The original issue was confirmed in comment 2)

(In reply to Andreas Jung from comment #17) > I think this bug's status should have stayed NEW. > (The original issue was confirmed in comment 2) Sorry

As described in bug 713889 comment 1, images' "numFrames" property is no longer exposed to JS (and it technically lived in an unstable "imagelib-private" section of imgIContainer.idl back when it was available). That change didn't cause this bug (it happened 5 months after this bug was filed, as I noted in comment 13), but it means that -- depending on how we fix bug 713889 -- we can't restore the frame-count anymore. We could, however, restore the "Type" field to display "GIF (animated)" at least, instead of "Background" (which is what I get in both a Firefox 3.6 build and a Nightly build, with an animated background image).

(In reply to Daniel Holbert [:dholbert] from comment #19) > We could, however, restore the "Type" field to display "GIF (animated)" at > least, instead of "Background" (which is what I get in both a Firefox 3.6 > build and a Nightly build, with an animated background image). Actually, it looks like the "Background" type is quite intentionally substituted for the actual image type, in pageinfo.js (using the "mediaBGImg" string). Maybe we want to keep that, but still report animated status, e.g. "Background (animated)". Assuming we don't end up re-exposing numFrames from imagelib, that strikes me as the best resolution to this bug. That would depend on bug 713889 being resolved first, though, because that's where we'd replace the string "(animated, %S frames)" with "(animated)"

This Issue (Comment 0) isn't a Regression, thus removing Keywords.