Last Comment Bug 632119 - For all data URI images, "View Image Info" says "Dimensions: 0px x 0px" & has broken "Media Preview"
: For all data URI images, "View Image Info" says "Dimensions: 0px x 0px" & has...
: regression
Product: Firefox
Classification: Client Software
Component: Page Info Window (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: Firefox 11
Assigned To: Felix Fung (:felix)
: Florian Quèze [:florian] [:flo]
: 666861 (view as bug list)
Depends on: 715075
Blocks: 377349
  Show dependency treegraph
Reported: 2011-02-07 11:24 PST by Daniel Holbert [:dholbert]
Modified: 2012-01-04 01:54 PST (History)
15 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

reference case (same image, as a file) (232 bytes, image/png)
2011-02-07 11:25 PST, Daniel Holbert [:dholbert]
no flags Details
Fix View Image Info for Data URIs (1.54 KB, patch)
2011-12-02 07:34 PST, Felix Fung (:felix) review+
Details | Diff | Splinter Review

Description Daniel Holbert [:dholbert] 2011-02-07 11:24:12 PST
 1. Load the following data: URI (for a green 100x100 block):


 2. Right-click on the loaded image, and choose "View Image Info"

ACTUAL RESULTS: The Image Info contains:
  "Dimensions: 0px x 0px"

  "Dimensions: 100px x 100px"

If I view the actual PNG image (not as a data URI), I get EXPECTED RESULTS.
Comment 1 Daniel Holbert [:dholbert] 2011-02-07 11:25:40 PST
Created attachment 510334 [details]
reference case (same image, as a file)

Here's the image that's encoded by the data URI in comment 0.  When you view this attached image directly (not as a data URI), you get EXPECTED RESULTS.
Comment 2 Daniel Holbert [:dholbert] 2011-02-07 11:35:14 PST
Additionally - for data URIs, there's a broken-image icon instead of the actual image, in the "Media Preview" box (at the bottom of the View Image Info).
Comment 3 Daniel Holbert [:dholbert] 2011-02-07 11:38:38 PST
See also Bug 599756, which was filed a few months back on similar issues with "moz-filedata:" images.
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2011-02-10 21:38:42 PST
Hmm.  So the page info code sets img.url and immediately reads the size.  So it assumes some sort of sync cache hit or something happening here.
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2011-02-10 21:49:17 PST
Actually, it looks like it never sets .url.  Investigating.
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2011-02-10 21:58:20 PST
And in particular, this check returns false:

  if (/^data:/.test(url) && /^image\//.test(img[COL_IMAGE_NODE].type))

because img[COL_IMAGE_NODE].type is undefined.  So checkProtocol returns false, and page info doesn't do anything with this image.

This is a regression from bug 377349 which moved some code around incorrectly (and replaced "mimeType" with "type" in the process).
Comment 7 Philip Chee 2011-02-11 00:19:42 PST
Setting to All/All as I can reproduce this on Win7
Comment 8 Alice0775 White 2011-06-24 01:13:12 PDT
*** Bug 666861 has been marked as a duplicate of this bug. ***
Comment 9 dindog 2011-06-25 09:31:14 PDT
so any plan to deal with this in recent? Maybe firefox 8?
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2011-06-27 09:59:34 PDT
Since tmyoung is not around, over to the bug 377349 reviewer.
Comment 11 Dan Jacobson 2011-11-18 14:04:59 PST
Indeed Firefox 10 users wonder
"speaking of which, why in Firefox when I click "View Background
Image" on an average Wikipedia page do I get
data:image/png;base64,iVBORw0... "1x1" pixels and all just white?
and in Page Info > Media there are several more, all "0x0" pixels.
Are they just all white nothingness, or is this a Firefox bug?"
Comment 12 Daniel Holbert [:dholbert] 2011-11-18 14:29:05 PST
(In reply to jidanni from comment #11)
> Are they just all white nothingness, or is this a Firefox bug?"

They're not white nothingness -- what you're describing is a firefox bug. (It's this bug, in fact! :) )

Note that this affects moz-filedata: URIs as well (e.g. it affects )
Comment 13 Daniel Holbert [:dholbert] 2011-11-18 14:33:23 PST
(ah, sorry -- the moz-filedata brokenness is covered by bug 599756)
Comment 14 Boris Zbarsky [:bz] (still a bit busy) 2011-11-18 14:39:13 PST
Gavin, can you find someone to fix this, please?

Note that the "View background image" issue is separate from this bug.  Please file a bug on it, with steps to reproduce.
Comment 15 Dan Jacobson 2011-11-18 14:56:55 PST
(In reply to Boris Zbarsky (:bz) from comment #14)
> Note that the "View background image" issue is separate from this bug. 
> Please file a bug on it, with steps to reproduce.
Just view the background image on Wikipedia. Same problem.
Comment 16 Daniel Holbert [:dholbert] 2011-11-18 15:01:44 PST
That works fine for me (it loads a 1x1 PNG image with a data URI directly). That's all correct so far.

At that point, if I then do view-page-info, *then* we hit this bug (because at that point we're basically following my STR from comment 0).

If that's what you're talking about, cool. If not, please file another bug, as bz requested.
Comment 17 Dan Jacobson 2011-11-18 15:21:43 PST
OK filed Bug 703784.
Comment 18 Felix Fung (:felix) 2011-12-02 07:34:29 PST
Created attachment 578578 [details] [diff] [review]
Fix View Image Info for Data URIs

- Fixed and simplified checkProtocol
Comment 20 Felix Fung (:felix) 2011-12-02 14:11:06 PST
This fixes the bug introduced by bug 377349 and makes data image URIs work. Is there any reason we don't allow _all_ data URIs to work as long as pageInfo.js can handle the object type (e.g. audio/video elements)?
Comment 21 Tanner M. Young [:tmyoung] 2011-12-02 14:17:24 PST
Felix: since we support audio and video tags already in page info, I would see no harm in this, but I can't remember if there is any other object type that can be handled through data:, if there is something like flash/javascript or another security-sensitive item (since page info currently runs in chrome), that would cause a problem--otherwise, being the person who wrote the original code, I see no problem.
Comment 22 Marco Bonardo [::mak] 2011-12-03 03:16:51 PST
Comment 23 Boris Zbarsky [:bz] (still a bit busy) 2012-01-04 00:10:28 PST
*** Bug 715075 has been marked as a duplicate of this bug. ***
Comment 24 Daniel Holbert [:dholbert] 2012-01-04 01:54:00 PST
For reference, here's a base64-encoded version of the image in comment 0:
(mostly posting for the purposes of discussion on bug 715075)

Note You need to log in before you can comment on or make changes to this bug.