Open
Bug 599756
Opened 15 years ago
Updated 2 years ago
View Image Info fails for images created from window.createBlobURL
Categories
(Firefox :: Page Info Window, defect)
Tracking
()
NEW
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: info, Unassigned)
References
()
Details
Attachments
(2 files, 1 obsolete file)
1.92 KB,
text/html
|
Details | |
765 bytes,
patch
|
Gavin
:
review-
|
Details | Diff | Splinter Review |
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.
![]() |
||
Comment 2•15 years ago
|
||
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.
Comment 6•15 years ago
|
||
Not holding the release for this, but I'd consider a safe fix for it!
blocking2.0: ? → -
Comment 7•14 years ago
|
||
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.
![]() |
||
Comment 8•14 years ago
|
||
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
![]() |
||
Updated•14 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
![]() |
||
Comment 10•14 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•14 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 :)
![]() |
||
Comment 12•14 years ago
|
||
Since tmyoung is not around, over to the bug 377349 reviewer.
Assignee: nobody → db48x
Reporter | ||
Comment 13•14 years ago
|
||
The API {create,revoke}BlobURL was replaced by URL.{create,revoke}ObjectURL.
Attachment #478660 -
Attachment is obsolete: true
Reporter | ||
Comment 14•14 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
Comment 15•13 years ago
|
||
(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
Updated•13 years ago
|
Assignee: db48x → ffung
Comment 16•13 years ago
|
||
- 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•13 years ago
|
Status: NEW → ASSIGNED
Comment 17•13 years ago
|
||
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
Comment 19•10 years ago
|
||
Images with src Attribute set to "blob:..." are also unavailable in Page Info dialog.
Comment 20•10 years ago
|
||
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).
Comment 21•3 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months.
:florian, could you have a look please?
For more information, please visit auto_nag documentation.
Assignee: felix.the.cheshire.cat → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(florian)
Updated•3 years ago
|
Severity: minor → S4
Updated•2 years ago
|
Flags: needinfo?(florian)
You need to log in
before you can comment on or make changes to this bug.
Description
•