Closed Bug 713889 Opened 8 years ago Closed Last year

In Page Info -> Media, the "(animated, N frames)" text is missing from the "Type" line, for animated <img>

Categories

(Firefox :: Page Info Window, defect)

defect
Not set

Tracking

()

RESOLVED INACTIVE

People

(Reporter: alice0775, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(1 file)

Attached file testcase
spun off from Bug 550686


Reproducible: Always

Steps to Reproduce:
1. Open the testcase
2. Tools -> Page Info -> Media

Actual Results:  
the frame count for regular images is missing.

Expected Results:  
The frame count should be shown.

Regression window:
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
Blocks: 584841
Confirmed on 64-bit linux. My 1.9.2 debug build has:
> Type: GIF Image (animated, 21 frames)
whereas my nightly build has:
> Type: GIF Image

It looks like pageInfo gets the number of frames here, by querying image.numFrames (where "image" is an imgIContainer):
http://mxr.mozilla.org/mozilla-central/source/browser/base/content/pageinfo/pageInfo.js?mark=890-892#886

BUT -- that property was indeed removed from the IDL (moved to the C++ class) in bug 584841:
http://hg.mozilla.org/mozilla-central/rev/f99cedbbc5f6
> Bug 584841 patch 11: Move remaining imagelib-private methods from imgIContainer interface to Image abstract class. r=bholley sr=vlad a=blocking 

Note that when the "numFrames" attribute existed, it was under the giant
>  /************ Internal libpr0n use only below here. *****************/
header in imgIContainer.idl, so it was technically naughty for pageInfo to be using it.

I don't think we want to re-expose the number of frames via imgIContainer.idl  (joe, correct me if I'm wrong on that).  It's a raster-image-specific value, and we shifted away from passing individual frame numbers around (instead passing enum values FRAME_FIRST vs FRAME_CURRENT).  Plus, even if it were available, I don't think it's particularly useful piece of information for Page Info to expose.  (nice as a "factoid" but not particularly important)

However -- the "(animated)" label *is* a useful piece of information to display (and is available on imgIContainer.idl via the boolean "animated" attr).  I think we should fix pageInfo to make sure *that* shows up correctly, regardless of whether we expose the frame count.
OS: Windows 7 → All
Hardware: x86 → All
So, to sum up, my vision for this bug would be the following three things:

 (a) Replace the numFrames check here with an "image.animated" check, to be sure we
     correctly report when an image is animated:
> 911       if (numFrames > 1)
> 912         imageType = gBundle.getFormattedString("mediaAnimatedImageType",
> 913                                                [imageType, numFrames]);
http://mxr.mozilla.org/mozilla-central/source/browser/base/content/pageinfo/pageInfo.js?mark=911-913#906

 (b) Remove all other mentions of "numFrames" from pageInfo.js (since imagelib
     no longer exposes that information)

 (c) Update the "mediaAnimatedImageType" string, to no longer include a frame count:
> 64 mediaAnimatedImageType=%S Image (animated, %S frames)
http://mxr.mozilla.org/mozilla-central/source/browser/locales/en-US/chrome/browser/pageInfo.properties?mark=64-64#64

Part "c" would be a string change & hence has l10n implications.
Summary: Page Info -> Media, the frame count for regular images is missing. → In Page Info -> Media, the "(animated, N frames)" text is missing from the "Type" line, for animated <img>
For this you'll want to do the standard way of changing a string, that is, changing the key. The "right" way to do so is to choose a good variable name, which would be much easier if the string was mediaAnimatedImageWithFrameCountType ;-).

You'll find something, worst case, mediaAnimatedImage2Type
OK, so part "(c)" in comment 2 should instead read:
  (c) deprecate the "mediaAnimatedImageType" string, and instead use a new string
      named e.g. "mediaAnimatedImageTypeNoFrameCount" that doesn't include a frame count.
(In reply to Daniel Holbert [:dholbert] from comment #4)
> OK, so part "(c)" in comment 2 should instead read:
>   (c) deprecate the "mediaAnimatedImageType" string, and instead use a new
> string
>       named e.g. "mediaAnimatedImageTypeNoFrameCount" that doesn't include a
> frame count.

mediaImageTypeAnimated ;)
Remember that reading image.animated can throw if we haven't downloaded or decoded the whole image yet.
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.