The Image Property Dialog (right click on an image -> properties) does not show the file size of the image. This might be an interesting - sometimes even an important - information.
this is a duplicate. Christoph, query for the original and mark this a duplicate. Some tips on querying can be found at http://www.mozilla.org/quality/help/beginning-duplicate-finding.html Thanks.
Are you sure this is a dup? This RFE was first filed in bug 66170, but that one contained several wishes for what an image properties window should display, and it was verified fixed, without the image size issue ever being implemented. One of the last comments in that bug reads: "We have a properties item now for images. Adding more useful information to it should be a separate bug." There is a resemblant bug 52730 about the "page info" window, but that one does not cover the content of an image properties popup triggered from context menu.
"Image properties" is different than "Page Info/Images" I can't find a dupe for this (15min search) but maybe I'm too stupid :-) So I'm marking this NEW
This is worksforme on Linux build 2001082922. It has been fixed by bug 82307. BTW, I noticed a strange behavior with Image properties. - http://bugzilla.mozilla.org/query.cgi - rclick on the banner - select Properties - click on the E-mail form to give it focus - write blabla in the form Expected: blabla is written in the form Actual: E-mail form has no focus and I can not write in this form Tell me if it is a dup. If it is not, I will file a bug.
Pierre Chanial: bug 82307 covers the "Image dimensions info" and not the "Image file size". Please search bugzilla for your problem and file a new bug if you can't find it.
Please ignore my last comment except the focus behavior. Image size is implemented. Not file size. Sorry.
This really is a partial showstopper for me re. using Mozilla :( I run several forums (phpBB) where we have avatars/usericons. These icons have a fixed size of 60x60 pixels.. People can enter just about any URL for their usericon so we manually check the sizes of the usericons when we are using the forum. In other browsers checking the filesize is easy, just a right click and hitting properties solves all your questions :D In Mozilla I either have to save the file somewhere and get the properties from the OS or I have to fire up an other Browser just to check out the size of an image :( Please increase the priority of this RFE..
*** Bug 120937 has been marked as a duplicate of this bug. ***
*** Bug 123138 has been marked as a duplicate of this bug. ***
adding "properties" to summary line for easier searching
Would be nice to show the size in bytes and kilobytes. Example: Size: 8558 bytes (9 kB)
I actually have this working in my local tree, it will be part of a bigger patch to fix some of the bugs filed on the properties window. What i've done is to show the filesize in bytes when below a certain threshold value, and in Kb when above. Not sure what i like best though. Maybe "9 Kb (8558 bytes)" is neater?
I really hate it when a program only shows the rounded value (in KB or MB).. Really annoying if you are testing what version of an image you are viewing, was it the new file (81262 bytes) or the new one? (82172 bytes). So IMO the number of bytes should be shown in any case.. Thanks :D
*** Bug 127561 has been marked as a duplicate of this bug. ***
Is there an ETA on this? Jonas?
That's what we have "Target Milestone" for
*** Bug 131561 has been marked as a duplicate of this bug. ***
*** Bug 144226 has been marked as a duplicate of this bug. ***
sorry folks :(
I suggest changing "OS" to "All".
16 years ago
The inability to determine an image's size gets annoying. I'm voting for this bug, and I think it makes the most sense to put the size in this format: Size: 64K (65401 bytes) This bug isn't hard to fix. Someone propose a patch!
Northman, you seem to know this code, because you know the easiness of it being fixed. So why not produce a patch? If you, on the other hand, do not know this code and can not provide a patch, please DO NOT comment on the easiness of fixing this bug! Thank you.
Christian Biesinger, why pick out one line of my previous comment for scrutiny? I'm POSITIVE it's easy. Look at download manager. That popped in overnight. I'm sure the guy worked on the code for at least a few days before he checked it in. This image size thing can be EASILY implemented by anyone who knows the mozilla code and has time and the ability. If you disagree, read over the last sentence. If I knew the code, I'd be announcing my patch (if I could get that patch thing to work), and I don't. However, the amount of code necessary to insert 1 line of end-result is quantatively limited.
download manager is completely different... it's for downloads, and (I suppose) it could use the code for the download progress window. however, elements of the page have no direct way to get their size. I suppose one could use the cache for that... assuming the image is cached.
I know all the code in question, and the closest that could be done without rewriting large chunks of code is the size of the image's cache entry. This is not really the size of the image if the image was compressed before going on the wire. That said, I think we should do that, and it would not be that hard... the code could be copied out of page info, which already does page sizes. As for download manager, that took many weeks of full-time work for someone. It was not "overnight" by any means.
well ok, I'll take this, and implement like pageinfo.
16 years ago
I agree with comment id 25. The compression is irrelevant. People who want to know the image's size want to know the image size in the cache. GZIP and whatever server-side compressions that are used are not to be a part of this. Excellent idea on taking it out of the page info window. I also stated in my original post, which comment id 27 agrees with that download manager was checked in overnight, but took time/ability/effort to do (days/weeks). I'm glad to see someone has a patch for this. Please everyone, if you're going to correct someone else, make sure your sure of what they said before you post.
Comment on attachment 93199 [details] [diff] [review] patch r=db48x technically I think it would be better in this case not to nest the try/catch blocks, since you return on success. That's personal taste though, no need to change that to get my r=
Created attachment 93208 [details] [diff] [review] patch v2 make change db48x suggested and change "Unknown" to "Unknown (not cached)" blake, could you sr?
Comment on attachment 93208 [details] [diff] [review] patch v2 marking r=db48x
> People who want to know the image's size want to know the image size in the > cache. Really? I want to know the actual image size (note that images are stored _compressed_ in the cache if the HTTP transaction was content-encoded).
Comment on attachment 93208 [details] [diff] [review] patch v2 sr=bzbarsky
Right, the image's actual size...as apposed to the size compressed with the gzip or whatever the server used to compress it (if anything).
Hmm, well that was an excellent fix, but now we've introduced another: bug 162378.
This fix would not have affected bug 162378. Something else is causing that.
*** Bug 165690 has been marked as a duplicate of this bug. ***
*** Bug 165690 has been marked as a duplicate of this bug. ***
vrfy'd fixed, 2002.09.16.08 comm trunk builds.