View Image Info fails for images created from window.createBlobURL

ASSIGNED
Assigned to

Status

()

Firefox
Page Info Window
--
minor
ASSIGNED
7 years ago
3 years ago

People

(Reporter: skierpage, Assigned: felix)

Tracking

unspecified
x86_64
Linux
Points:
---

Firefox Tracking Flags

(blocking2.0 -)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b7pre) Gecko/20100925 Firefox/4.0b7pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b7pre) Gecko/20100925 Firefox/4.0b7pre

I played with https://developer.mozilla.org/samples/domref/file-click-demo.html , a demo of window.createBlobURL (and other things).

After selecting an on-disk image, it previews (cool).  The sample immediately calls revokeBlobURL() which means several image operations such as View Image don't work.  But even if you comment out revokeBlobURL(), View Image Info displays a broken image and says Size: Unknown.


Reproducible: Always

Steps to Reproduce:
1.  Modify https://developer.mozilla.org/samples/domref/file-click-demo.html to comment out the call to revokeBlobURL()
2.  Load the HTML file, click and select a local on-disk image.
3.  Right-click the image preview shown and choose View Image Info
Actual Results:  
Page Info > Media appears and shows the element address (moz-filedata:xxxxx), but Size is Unknown (not cached), Dimensions are 0px x 0px,  and Media Preview shows nothing.

Expected Results:  
Shoule View Image Info work for moz-filedata blobs?  If you right-click on the image and choose Copy Image Location and paste into another tab, you can preview the moz-filedata:xxxxx URL fine, so it seems Firefox knows about image blobs if you don't look too closely ;-)

createBlob() is implemented in dom/base/nsGlobalWindow.cpp and is not yet in http://dev.w3.org/2006/webapi/FileAPI/#blob , so I guessed a bugzilla component for it.

If you leave in the sample program's call to revokeBlobURL(), several other image operations fail (View Image, Save Image As..., Copy Image Location) but I think this is to be expected.

Save Image As... suggests "index" as a name and proposes no extension for JPEG files, I don't know if those are bugs.
(Reporter)

Comment 1

7 years ago
Created attachment 478660 [details]
MDC "Using blob URLs to display images" with revokeBlobURL() commented out
Jonas, any idea what's going on here?  Is some security check failing?
No idea, but I'll take a look.
Assignee: nobody → jonas
blocking2.0: --- → ?
(In reply to comment #0)
> Save Image As... suggests "index" as a name and proposes no extension for JPEG
> files, I don't know if those are bugs.

Based on this, I think this is likely to be the same underlying issue as Bug 599367.  I'll test tonight.
Nope, I was wrong.  There are no security errors in the console either.
Not holding the release for this, but I'd consider a safe fix for it!
blocking2.0: ? → -
See also Bug 632119, which I've just filed on similar issues cropping up in data:URI images.  It may be a more generalized version (or alternate way to hit) this same bug.
This isn't a DOM issue.  Page Info has a protocol whitelist, and moz-filedata: isn't in it.  See checkProtocol() in pageinfo.js.
Assignee: jonas → nobody
Component: DOM: Core & HTML → Page Info
Product: Core → Firefox
QA Contact: general → page.info
Status: UNCONFIRMED → NEW
Ever confirmed: true
Looks like this whitelist is fallout from bug 377349.
Blocks: 377349

Comment 10

7 years ago
attachment 478660 [details] doesn't work for me at step [3] No image previews. Tested on Win7/x64 with both Minefield and SeaMonkey 2.1b3pre.
(Reporter)

Comment 11

7 years ago
(In reply to comment #10)
> attachment 478660 [details] doesn't work for me at step [3] No image previews. Tested on
> Win7/x64 with both Minefield and SeaMonkey 2.1b3pre.

Maybe there's a problem with the MDN code?

With Firefox nightly (Mozilla/5.0 (X11; Linux x86_64; rv:2.0b12pre) Gecko/20110207 Firefox/4.0b12pre), the image I select still previews, and I still see the wrong info in context menu > View Image Info and/or Tools > Page Info then the Media tab.

I notice that in Firefox nightly neither context menu > View Image nor context menu > Copy Image Location then paste URL into a new tab displays the full-sized moz-filedata:blahblah image, they do nothing; whereas both still work in my older SeaMonkey 2.1b1 (Mozilla/5.0 (X11; Linux x86_64; rv:2.0b7pre) Gecko/20101008 Firefox/4.0b7pre SeaMonkey/2.1b1).  I don't know what's intended to work, so I'm not filing a new bug for this :)
Since tmyoung is not around, over to the bug 377349 reviewer.
Assignee: nobody → db48x
(Reporter)

Comment 13

7 years ago
Created attachment 542321 [details]
MDC file input demo with revokeObjectURL commented out

The API {create,revoke}BlobURL was replaced by URL.{create,revoke}ObjectURL.
Attachment #478660 - Attachment is obsolete: true
(Reporter)

Comment 14

7 years ago
Comment on attachment 542321 [details]
MDC file input demo with revokeObjectURL commented out

Trying the revised HTML with the latest Firefox nightly "Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110625 Firefox/7.0a1" context menu > View Image Info and/or Tools > Page Info then the Media tab still give wrong info.

The problems I mentioned in comment #11 with viewing the moz-filedata:blahblah image are gone.
Attachment #542321 - Attachment mime type: text/plain → text/html
(In reply to skierpage from comment #0)
> Steps to Reproduce:
> 1.  Modify https://developer.mozilla.org/samples/domref/file-click-demo.html
> to comment out the call to revokeBlobURL()
> 2.  Load the HTML file, click and select a local on-disk image.
> 3.  Right-click the image preview shown and choose View Image Info

Simpler STR:
 1. Load this URL:
http://mxr.mozilla.org/mozilla-central/source/layout/reftests/svg/as-image/img-blobBuilder-1.html
 2. Right-click the green square and choose "View Image Info"

ACTUAL RESULTS: Same as comment 0
(Assignee)

Updated

6 years ago
Assignee: db48x → ffung
(Assignee)

Comment 16

6 years ago
Created attachment 578742 [details] [diff] [review]
Acknowledge data: and moz-filedata: for View Media Info

- checkProtocol returns true for data and moz-filedata
- this should still be safe since we still cheeck and only perform actions on a limited (explicit) set of items (HTMLImageElement, AudioElement, etc.)

See: bug 632119 comment 21
Attachment #578742 - Flags: review?(gavin.sharp)

Updated

6 years ago
Status: NEW → ASSIGNED
Comment on attachment 578742 [details] [diff] [review]
Acknowledge data: and moz-filedata: for View Media Info

You don't actually need to whitelist all of "data:" to fix this bug, right? I'm not confident that's safe, so it's best to avoid doing that.
Attachment #578742 - Flags: review?(gavin.sharp) → review-
Note that we're renaming "moz-filedata" to "blob" in bug 716570
Images with src Attribute set to "blob:..." are also unavailable in Page Info dialog. 
Images with src Attribute set to "blob:..." are also unavailable through Page Info dialog. 

For example Google uses this technique which "protects" images from being saved by the user, see

  https://drive.google.com/viewerng/viewer?url=patentimages.storage.googleapis.com/pdfs/US7770666.pdf

Open Page Info and select Media tab. There, addresses starting with "blob:" are unavailable. Their content is neither displayed nor can it be saved ("Save as..." button fails to save the image).
You need to log in before you can comment on or make changes to this bug.