[RFE] Implement .fileSize for images




16 years ago
6 months ago


(Reporter: Andy Edmonds, Unassigned)



Firefox Tracking Flags

(Not tracked)



(3 attachments)



16 years ago
IE compatibility feature.  Useful for doing "webGarage' style activities on pages.
May be useful, but not important enough to be implemented anytime soon unless
someone contributes a fix. Future.
Target Milestone: --- → Future
I was looking at this.... how would this act in the case of images that are not
shown (eg display:none or something)?  In those cases we don't even fetch the
image from the server...  What does IE do?

In general, what is the _exact_ behavior of this feature for the following

1)  <img style="display:none">
2)  <img>
3)  var img = new Image();
4)  var img = new Image(); img.src = "http://foo.bar.com/";

Comment 3

16 years ago
having display=none gives you the fileSize of the image
having <img> produces -1 as fileSize
having new image produces -1 as fileSize
having new image.src produces -1 as fileSize

Comment 4

16 years ago
Created attachment 89248 [details]
img fileSize test that works in IE
What happens if you do 

var img = new Image(); img.src = "http://foo.bar.com/";

then insert the image into a document?

Comment 6

16 years ago
then you have to wait for the image to load and I didn't do that.

If you just do:
var img = new Image();
img.src = "http://gemal.dk/pics/mail.gif";

it's "-1"
OK, what happens if you want for the image to load?  The idea here is not to
pull information like teeth but to come up with a full description if we're
going to implement a bug-compatible behavior... ;)

Comment 8

16 years ago
if i do:
var img = new Image();
img.src = "http://gemal.dk/pics/mail.gif";
for (var i=0; i<100000; i++) {

I get "151"
Does that empty for-loop actually do any good? I can't see how it would...

Comment 10

16 years ago
the for loop is just to give some time for the image to load
But the loop blocks the main thread from doing anything, I doubt the image would
load completely while the main thread is blocked... Or maybe it manages to load
on the imagelib threads even with the main thread blocked, who knows, in either
case, the result of a loop like that one is unpredictable at best, so I would
strongly suggest not using such loops ever.

Comment 12

16 years ago
Created attachment 89306 [details]
test case use img onload to wait

Comment 13

16 years ago
According to the MSDN this property applies to img and document elements:

I think that maybe if it's implemented in Mozilla it could be extended to work
with  any element that represents a file (if possible of course), just like it's
shown in the Page Info (General and Media tabs)
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
So I just read the MSDN page again. The following questions naturally arise:

1)  What units is the file size in?
2)  What is meant by the file size?  The number of bytes that went over the
    network?  Or the amount of data in the image file?  (In the face of
    gzip-encoding these are different numbers.)  Or does it mean the decoded image
3)  What size is reported if there is no Content-Length header for the image

Any information would be much appreciated.

Comment 16

15 years ago
Created attachment 121660 [details]
new test for fileSize

1. bytes
2. I think that the original file size as seen in the OS (I'm not sure about
the gzip)
3. I think that it shouldn't affect (just apply reply 2), just show the amount
of bytes that the file uses in the cache.

Anyway, this test allows to select the url of any image in order to test what
happens under any of the scenarios that you have described, if you don't have
an IE at hand just post some urls that you think that can help you and I'll
give you back the results under win98, IE 5.5.

I think that IE uses this same call to show the file size in the properties
window after right clicking an image, so Mozilla should use the same file size
that it's shown in its image properties window.
> just show the amount of bytes that the file uses in the cache.

Things sent with content-encoding:gzip are stored gzipped in the cache.  That's
what page info shows, and getting it is not guaranteed if the image is NOT in
the cache.  So I'd rather not do it that way...

I'll post testcases sometime, but this is pretty low-priority for me, so...

Comment 18

11 years ago
fileSize really becomes important when you start to do client-side apps working with web content... no prospect of fixing this one?
Did you read the bug before commenting?  In particular, the questions in comment 15 and comment 17 need answers before this can get implemented.  There's no point implementing this if we'll give different answers than IE.

Comment 20

11 years ago
Actually, i don't need it as IE compatibilty, i need it as a developer to write javascript extensions for Firefox exclusively that work with remote files...

If you're doing an extension you already have access to the cache APIs, etc.  So you can always get this information from them.

Comment 22

11 years ago
I've tried today again and I haven't been able to find any image served gzip-ed so I can answer only based on document.fileSize for gzip-ed content:

If a page is served as gziped then document.fileSize of that document shows the uncompressed size, just the same info that it's shown in the properties of the page. (IE 6, wXP) 
Firefox shows in the properties info page the compressed size of the document as it was served (and stored in the cache). 

I think that answers the 2nd question, for the third I just don't know right now how to find set up such a page if anyone can point me to such a page I can run a test (javascript:alert(document.fileSize)) but I think that the answer will be the number of bytes of the uncompressed page.
Assignee: general → nobody
QA Contact: gerardok → general

Comment 23

6 months ago
It seems like Edge dropped this feature. If it's still desired, please go through the standardization process first: https://github.com/whatwg/html/issues/new.
Last Resolved: 6 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.