986 bytes, patch
|Details | Diff | Splinter Review|
1.60 KB, patch
|Details | Diff | Splinter Review|
5.22 KB, patch
|Details | Diff | Splinter Review|
5.14 KB, patch
|Details | Diff | Splinter Review|
5.03 KB, patch
|Details | Diff | Splinter Review|
Having the filename shown in the context menu can very often be very useful.
Clarification: That is, the context menu when you right-click on an Image.
Moving this to UE/UI component and reassigning for consideration and appropriate reassignment...
reassign it to german to make final call in design.
spam: reassigning QA contact to self.
*** Bug 24477 has been marked as a duplicate of this bug. ***
Moving all UE/UI bugs to new component: User Interface: Design Feedback UE/UI component will be deleted.
Either this is a duplicate of 24214 or vice versa.
*** Bug 24214 has been marked as a duplicate of this bug. ***
*** Bug 34228 has been marked as a duplicate of this bug. ***
Yes, name of image should appear in parenthesis after "View Image ( <name> )" Please reassign to correct engineer to implement.
Please assign to correct engineer to be implemented.
communicator 4.x already has this...why must we wait till post-6.0 to implement this? sounds like a step backwards, imho.
Put this on the PDT radar for beta 2 ... (Bill, don't panic.)
Putting on [nsbeta2-] radar. Not critical to beta2. Adding nsbeta3 keyword.
Move to M20 target milestone.
Actually, the filename should probably appear after `Save Image As ...' rather than after `View Image', shouldn't it? You're much more likely to care about the filename when saving the image than when viewing it. So `Save Image As ... (picture.png)' would indicate the default filename when saving the image, just as `Zoom ... (100%)' would indicate a default zoom level when opening a Zoom dialog, etc.
How 'bout "Save Image As (picture.png)..." ? I always put my elipsis at the end of the menu text. Either way, that should most likely be a separate bug.
If you look at the context menus in Netscape 4.x (maybe even earlier) you can see that the "View Image (filename.ext)" can easily be the longest entry (depending on the filename). Putting the filename after "save image as" would only make the menu wider. The user would still see the filename regardless of what he or she wanted to do (save image or view image, etc.) Also, if the user was to save the image he or she would see the filename in the save as dialog anyways.
> Having the filename shown in the context menu can very often be very useful. Can you please elaborate on this. I've personally *never* cared to see the file name until such time as I've selected "save image as...". I could see where maybe some web surfer might be curious as to whether the author of a page chose to use PNG vs. GIF or something, but what use is the name, otherwise?
It does seem to be trival, but here are some ideas on why it's useful. 1. If a webpage designer did not include alt text sometimes the filename gives an idea of what the image is suppose to be. (esp if images are turned off) 2. Checking the file type 3. You could eaisly tell if you have the right image when you're making a webpage. 4. Easily tell if a group of links are seperate images or an image map. (See the tabs used at go.com) I can't think of anymore at this moment, but this bug was duplicated twice and has 4 votes, I hope someone else can give more (better?) reasons to have this feature.
Removing self from cc. Will catch in nsbeta3 reviews in future.
1. Alt text defaults to the url if not explicitly provided, no? 2. Yes, that's the one I mentioned; not clear how compelling this is. Most users certainly don't care, and I'm not sure why anybody else would till such time as they decided to steal the image for their own use. 3. Doesn't composer image properties convey sufficient info? 4. OK. I've been just dying to know if go.com was using separate images or not, too :-). That's kind of what "view source" is for, though. I'm just being the devil's advocate. This isn't that hard to do (aside from some additional l10n complexity) but it does stretch the menu and I'd like to know there was some reason other than "Communicator does it" (although that's a fine excuse to *avoid* doing extra work).
This is the first Bugzilla comment I'm leaving. This is also the only bug I'm watching, if my memory serves me right, even if I'm a frequent Bugzilla lurker. You can see this as a cry of despair :-) There are numerous reasons for it to be left where it is. This feature is, if not essential, so VERY useful for professional web developers (such as myself). Just a few simple examples: * Easy to check the output of "scripted images" (IMG SRC="image.php?id=3") -- this is very repeat VERY important for debugging database pages with BLOB images (getting much more frequent these days) * Easy to check the name of a file to be able to find it in a directory with lots of files * Easy to see if links are images or written text or made with an image generator * Easy to see if links are image maps, or lots of cropped images. This is also a great time-saver for web development. * If you open a page, just a few right-clicks is enough to get an impression of how the page is coded. You could do that by viewing source -- but it would take longer time (especially with **** coding) and not be as logical as a graphic representation. You could view info, but that would only give you info about the images, no structure. A great HTML coder can open a page in NN and tell exactly how it's built, using only the right mouse button. * You can easily see if the right file type has been used for a specific kind of image. Yeah, you could use "view info" for that too, but the whole point is that this tiny tiny feature makes things faster and easier. Why is the file type important? Sometimes (often) you will "take over" projects from other people. Using JPEGs for text-type images is a Bad Thing, as we all know. You can easily check if you have to remake the image, or if the image is editable (for small changes in an image you can open the GIF and "pixel edit" it. JPEGs can't be tampered with that way due to the destroying compression method) It really is -- for me -- the most used "special" feature in NN (one of the "extras" IE doesn't have, together with "open frame in new window" and the dimensions of a picture in the title bar when choosing "view image"). Yes, you can accomplish this in IE with properties, or in any browser by viewing the source, or by viewing properties, or by choosing "save as", but that's a lot of extra clicks, and that's a great annoyance. Make it a preference -- it is, as you said, very easy to code -- or a hidden feature only accessible by editing the prefs file, or whatever, but PLEASE PLEASE PRETTY PLEASE, with sugar on top, put it in :-) This is one of those features which establishes loyal users. And if the time spent here discussing the feature had been put into coding it and making it a checkbox preference under "advanced" it could have been coded weeks ago. Just a few words about myself, so you can see that I'm not the standard Bugzilla whiner. I have been into web development for five years; I am a designer and occassional programmer at one of Swedens largest web agencies; and I have been working with HUGE webs for major global companies. Where I work, I am famous for 1) my HTML skills and 2) my die-hard NN addiction. If you took away this feature, I know that the few of us who are still using Netscape and are looking forward to the Mozilla release would switch to IE right away. Wow, big threat, huh? :-) But I just want to tell you that even if you Mozilla coders can't see that this would be a useful feature of Mozilla, a couple of thousand Netscape users who love this feature would be a very happy lot if you chose to let it stay. And a hint: No pro would even dream of using the Composer anyway.
I will also add my support for adding this feature. It is *VERY* convenient to have the image name be displayed with a simple right-click. Aside from all the great reasons already mentioned, sometimes a webpage will display a picture without providing a caption or information about the picture. Many times in that situation you can learn more about what the picture is about, by looking at the filename for the picture. This is much easier to do in Navigator, because all you have to do is right-click once. If this was not there, you would have to go into the source, and search for that image (which you don't know the name for anyways). As far as the Context menu being stretched, this feature was in Navigator, and did you ever hear anyone complaining that the context menu in Navigator was too big?
NN cropped the filename for long names, which makes perfect sense. NN transformed 1234567890asdfghjkl.gif into 12345...jkl.gif (or something like that) so the context menu were never stretched.
Bill, current spec is for Mozilla *not* to use the filename as alt text when no ALT attribute is specified (see bug 41924). In any case, that doesn't help if the image is loaded, because if it is loaded you won't be able to see the alt text at all, not even as a tooltip (see bug 1995). Hopefully Mozilla (and its derivatives) will become the browser(s) of choice for developers, so we can all enjoy a more standards-compliant Web; and this is one small but important step towards making sure that happens.
OK, we aim to please, even when you might be wrong :-). I'd just as soon implement this as work on some of the really nasty bugs I have...
*** Bug 43920 has been marked as a duplicate of this bug. ***
nav triage team: nsbeta3-
Seems like an obvious candidate for helpwanted -- small problem, low risk, geek feature. :-) Also resummarizing (see my comments on 2000-06-14).
Please please please get this feature in as soon as possible! I've soo missed you, filename! :)
anyone want to review this? This would be neat to have in nsbeta3/m18.
Can't this go in for RTM? Surely this is a VERY low risk patch? And it would be very very nice to have this feature again
um, not likely :)
hehehe, no not likely at all! :) Having it on the trunk would be nice too though... Besides someone might want to update the target milestone here?
I'm going to attach a copy of this patch to the bug, in the hopes that we can shepherd this into mozilla0.9 or thereabouts. Here are some of my rules [obviously you should conform to them], they apply while I own this bug or any other bug. 1. don't touch the status whiteboard unless you are assignee (me), QA, PDT [in the event I invite PDT] or are otherwise invited by assignee (me). 2. Don't touch the milestone. That is for the assignee (me). 3. This bug does not need clarification so I do not need to see comments from people not directly working on this bug. 4. If you have questions please feel free to contact someone via irc or email. 5. This is an open project, if you don't like my terms, feel free to volunteer to fix this bug yourself, it's your right and I will help you in this activity. 6. There is a proposal for bug commenting guidelines, if you would like to read them I will send you a copy. </notice> James Cooper: thank you very much for working on this. One thing that I will change is avoiding a multiline string in oncreate=... Actually I hope you'll like my approach (it might still not be separated enough, but the basic location is better). mpt: The save image as dialog will have the suggested name, but as you may remember it will also allow various manglings and such, therefore putting the name there makes no sense. One question: Could I change from: View Image (something.jpg) to View (something.jpg) I'm not quite sure how we define an image, but, I can imagine prefering to omit the word Image.
Created attachment 19221 [details] [diff] [review] Proposed patch to nsContextMenu.js adds file name to view image
> Could I change from: View Image (something.jpg) to View (something.jpg) No. Many users are unaware that images have goofy names like hgb03large.png, so if the menu item just says `View (hgb03large.png)' they will ignore it and assume that the ability to view the image is not present in the context menu at all.
On a related note: I have started to use the "block image from loading" context menu quite a bit. It seems the behaviour of this menu keeps all images on the domain from loading. If I want to block ads, I am constantly having to view page source or view image to see if the ads on the site are hosted on the same domain as the other images on the site. It would be really great to have the context menu for "block image from loading" have a similar note next to it. Something like: "block image from loading (images.foo.com)" There are some length problems and everything, but it would be a great feature. I thought that somebody familiar with the patch for this bug could whip something up rather quickly. Should I submit a separate bug report?
Showing the domain which an image came from could be achieved by bug 33576, without obfuscating the image context menu for ordinary users.
*** Bug 60800 has been marked as a duplicate of this bug. ***
ok, fabian and I just wrote the same patch without knowing about this one, identical (duh). So, what is it going to be? After view image, save image as? We could also put it alone as the first or last item, but probably UI people would disagree. We should check this in for 0.9/ns6.5
attaching patch that Fabian and I did. It utilizes some of Timeless's patch. I hope I did it correctly (the diff). This patch is probably not final..the url trimming should be functionalised so that others can use it (inside communicator and outside).
*spam* forgot to say, on linux, on long image names, the name gets cutoff. this seem to not happen on windows. This is another bug in mozilla, will file/search for it
mpt - for composer, where should "Save Image (imagename)..." go in the context menu? I have now a patch for all 3 main components (composer, mailnews and browser). taking the liberty to punt this bug to me and let timless fix other bugs ;)
*** Bug 64481 has been marked as a duplicate of this bug. ***
*cough* anything left to do here?
added patch, removes a useless entity (save image as...), as it is retrieved from the stringbundle
r=bzbarsky for the latest patch
ccing email@example.com for a sr= if possible
no! please use nsIStringBundle.formatStringFromName() to format this string, instead of using the s/// operator.
new patch with suggested changes, thanks for alecf for answering my questions regarding that
looks great. sr=alecf
fix is in.
Bugs are verified on all platforms against which they're reported, and this information is given.
Works on Win32 2001012404, and also verify that it truncates long filenames. Although it truncates it as "Save Image (long_long_long..." instead of "Save Image (long_long_lo...name.gif)". I think the second is better, but the first is definitely better than nothing.
dean, i agree with you there... doron, should this be reopened, or shall i file another bug re: truncating long names mo' bettah? thx...
File a new bug. Mark this one as blocking that one. Thx Verify based on comments by dean and se.
file a new one. currently classic will not cut it of btw, that is a known bug in the classic theme.
added 66683 - messes up in non-navigator sidebars, argh
If you right-click on an image that's a link, there's a duplicate access key between Save Link As and Save Image (A). Was this introduced by this fix, or was it always around?
*** Bug 117684 has been marked as a duplicate of this bug. ***
new menus don't show image filename after 'Save Image ...'. Reopening.
You best open a new bug on UI Design, as this was removed in the latest spec
bug 136110 is gonna take care of adding back the filename, so marking this one fixed again.
Excuse me, what is the reason for marking this fixed? It has regressed. So, reopened is the correct state. If you want to resolve it, then you should mark it as a duplicate of 136110, or vice versa. Reopening.
*** This bug has been marked as a duplicate of 136110 ***
mass-verification of Duplicates. mail search string for bugspam: SolarFlaresAreTheCause