From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020404 BuildID: 2002040403 In old releases and in Communicator there was context menu option View Image (imgname.extension). In the new release there is an option View Image. So, you cannot see image name until you open Properties. I think, it is not comfortable.

-> blake

*** Bug 137052 has been marked as a duplicate of this bug. ***

qa --> sairuh@netscape.com

I can see the image name in the context menu near to Save Image (ok, it's not near to View Image, but all the same you can see the image name when you right click on it) I'm using build 2002040203 on Win98 and I don't think it has been removed two days after in build 2002040403 Unless I'm wrong, or someone would like to move the image name from Save Image back to View Image, this bug should be marked as WORKFORME

Valerio, please get a newer build. The context menu changes came in after 2nd April 2002 afaik.

-> marlon

*** Bug 138406 has been marked as a duplicate of this bug. ***

Using 1.0 RC1 (2002041711, Windows ME), the image name does not appear in any part of the image context menu. This is a regression from the previous menus where the image name appeared. Adding regression keyword and setting severity to normal.

*** Bug 140807 has been marked as a duplicate of this bug. ***

*** Bug 141938 has been marked as a duplicate of this bug. ***

One of the (many) reasons I don't like IE is because you can't get names with a simple rmb action. Please fix for 1.0 :)

I vote for fixing this as well. I've always preferred Netscape/Mozilla over IE because of the little quirks in the UI, and this was one of the big ones.

I would also like to see this re-implemented. This small feature is one thing that sets Moz apart from IE. Sidenote - the workaround of selecting the "View Image" doesn't work to get the name. This happens in the case of poorly coded HTML docs from WSYIWYG editors that create garbled, unusable, "localized" links. Because of those bad links, one can't just select "View Image" to get the image name from the URL because Moz doesn't know where to look for the image. Please fix for 1.0.

Ok, I tried to track it down and ended up here: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/xpfe/communicator/resources/content&command=DIFF&root=/cvsroot&file=nsContextMenu.js&rev1=1.62&rev2=1.63#7 Supposedly putting that bit of xul code back in should get the image name back. I don't have time to try it right now, anyone else want to look into it?

Taking. Patch coming up...

Really taking...

This patch restores the "Save Image As..." context menu item to the state it was in before the context menus were reworked around 04/02. It still needs testing.

Seeking review. Note that this patch contains no original code, it just puts back code snippets that were taken out in the context menu rework. The CVS logs for that checkin are here: For xpfe/communicator/resources/content/nsContextMenu.js: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/xpfe/communicator/resources/content&command=DIFF&root=/cvsroot&file=nsContextMenu.js&rev1=1.62&rev2=1.63#7 For xpfe/communicator/resources/locale/en-US/contentAreaCommands.properties: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=contentAreaCommands.properties&root=/cvsroot&subdir=mozilla/xpfe/communicator/resources/locale/en-US&command=DIFF&rev1=1.9&rev2=1.10

Does anyone know how to get advice from people with UI knowledge? For example, in 4.x the image name appeared in the View Image Command, in Mozilla it appears in the Save Image command. We might as well change it now while we're at it...

Lorenzo: You should ask Matthew Thomas (cc).

mpt, what do you think? Should it be: View Image (blah.gif) Save Image As... or View Image Save Image (blah.gif)...

The latter. The filename is much more relevant when you're saving than when you're viewing.

Virtually identical to patch v1 but fixing jkeiser's nits.

Yeah, I'd like to see this feature put back in as well. I used it a lot before, and miss it now.

taking, since I wrote the original and have some improvements in mind.

*** Bug 155553 has been marked as a duplicate of this bug. ***

*** Bug 156099 has been marked as a duplicate of this bug. ***

If the improved patch isn't going to be ready for 1.1, is it at least possible that the patch currently attached to this comment can be used instead? Since the current patch is simply putting back in the old code, it shouldn't be much of a risk.

I'm not sure we should even do this unless its correct

What issues are there with the patch that's here? I never saw any problems with the feature before it got removed. I'd be willing to take a shot at fixing it if I knew what the holdup was.

a) should this even be done? The info is availabe via proeprties b) long names would cause the context menu to display wierdly

re #31: a) judging by the discussion (and 11 votes) it should be done. Using the Properties dialog is slower. b) it is always possible to display only some first 20 letters of a filename in case it is too long. How many pages use image names like: "Marcus Aurelius being celebrated in front of the gates of Rome as he returns from the battle"?

It should most certainly be done. It's extraordinarily handy. For really long names, just truncate with ellipses at the 17th character if the filename is more than 21 chars, for a completely arbitrary (but reasonable) cut off point. Even from only a developer's standpoint, it's incredibly handy to see what image is placed where with a SINGLE mouse click. And considering it was in for a very long time AND a 4.x feature, there's no real reason not to do it. Long names can be truncated. And to preempt a UI debate, yes, my suggestion is completely arbitrary, and based on nothing but a brief glance at the current context menu's size, and conclusion that a 20 character max is reasonable.

I had it stop at 17 before it was backed out. I want some UI design folks to speak, not developers

Why should this be done? Here's my personal testimony: I used this feature for 7 years. Is that good enough? AFAIR, every version of Netsacpe until someone yanked this from the Mozilla tree supported this, and I often used it as a quick way of glancing at file names. When I noticed it was gone, I duped this bug rather quickly. It's a bug to have such an easy to implement feature (just truncate large names, etc) which is useful in many situations removed. It's like removing alt+left arrow because the BACK button at the top of the browser works as well. It doesn't, that's why this bug is here. It's also another reason I hate IE! :)

is there anyone who isn't a web developer that would want this ? Why ? Some people explaining what they use it for might help ..

When NOT using it in the vein of webdevelopment, I use it for curiousity's sake and when downloading images (knowing if I have to rename it ahead of time).

Some cases where I've used this feature... * I've come across sites that use images to provide color coded bullets to convey information about items in a list. Unfortunately, sometimes these sites used colors that were not very distinct, so the easiest way to figure out what information the bullet was supposed to convey was to check the filename of it. * If I see a picture of something, but don't know what it's called, then the filename might give a hint. I can vaguely remember once reading a Star Wars article that had pictures of a bunch of different vehicles from the movies. None of the pictures were labeled however. Right click, and I see something like atat.jpg or tie.jpg, and it makes the article make more sense.

This "bug" has my vote. I want this option back in Mozilla too! The previous functionality was a lot better IMO.

*** Bug 21515 has been marked as a duplicate of this bug. ***

Adding "blocks bug 66555" from duplicate bug 21515.

Another good reason why this feature should be brought back... even from an end-user point of view. Imagine a page that use a big image for background that has been split in sub-image to speed up the loading time (a not so good example is http://www.ntu.edu.sg/index_hi.htm but I'm sure you have better). Now imagine I want to save the complete graphics I need to do it 'part by part' - but here come the problem, we don't see where the sub-images end or start, because there are jointed seamlessly, thus we don't know where to right-click! This will be helped a lot if at least we know the name of the image as soon as we right click, and thus see that we are still 'on the same sub-image'. Those 'table assembled' image are still quite common on the internet...

This is a screenshot of the NS4.8 context menu when brought up on an image. It shows 16 characters of the name, the beginning few and the end few with an ellipsis in the middle, the period, and the 3 char extension. If this was ok for years in a commercial product, I see no reason why we can't get it in here. It passed NS's UI people for a LONG time. Since the users want it, it REALLY should be there.

I know the following statement may sound a a flame, but I consider it to be a public outcry! As explained in comment #43, loads of useful features present in Netscape up to version 4.8 were sacked/ignored/horribly redesigned in Mozilla. I can think of many examples spanning many bugs. I've seen only a few fierce debates over basic expected behaviours being brushed aside with an arogant WONTFIX, fundamental issues being discussed for years and still no fixes in sight, with many potential users of Mozilla trying it and then discarding it. Even as bug reports complain about these missing features continue to pop-up and as duplicates being filed, little action is taken.

It seems that programmers tend to add new code and features (which often supply new bugs) instead of fixing persent bugs first. Personally, I don't have anytrhing against new "cool" features however old bugs are _VERY_ annoying, forcing me to use NS4.8 rather than Mozilla for some activities.

I always used this feature, and never understood why it was removed. Why WAS it removed? Can we ever expect it to return? If not, why not?

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

(In reply to comment #47) > If you can confirm that this report still applies to current SeaMonkey 2.x > nightly builds, please set it back to the NEW state along with a comment on how > you reproduced it on what Build ID, or if it's an enhancement request, why it's > still worth implementing and in what way. Bug still exists in currently nightly builds. Re-marking as NEW.

We're not planning on doing this in SeaMonkey right now. Please offer this as an add-on for SeaMonkey 2 if you can, if that one is used by a lot of people, we can still think of integrating it, but right now I see this as WONTFIX.

Updated patch for SeaMonkey 2.0b1pre, including the fix from bug 81295 and a 20 character maximum.

Comment on attachment 384966 [details] [diff] [review] SeaMonkey 2.0b1pre version of Lorenzo Colitti's patch v2 Some of the indentation in the new code didn't make sense. > // Save image depends on having loaded its content, video and audio don't. > showSave = this.onLoadedImage || this.onStandaloneImage || this.onCanvas; > if (showSave) > goSetMenuValue( "context-saveimage", this.autoDownload ? "valueSave" : "valueSaveAs" ); > this.showItem( "context-saveimage", showSave ); >+ if (this.onImage) { //if onImage, let's get the imagename into the context menu Except we actually show the menuitem for onLoadedImage, onStandaloneImage or onCanvas... >+ var fullName = this.imageURL; This variable is out of date and only provided for backward compatibility. >+ //For "http://foo/bar/cheese.jpg", return "cheese.jpg". >+ //For "imap://user@host.com:143/fetch>UID>/INBOX>951?part=1.2&type=image/gif&filename=foo.jpeg, return "foo.jpeg". >+ if (fullName.lastIndexOf("filename=") != -1) >+ var imageName = fullName.substring(fullName.lastIndexOf("filename=") + 9) >+ else >+ var imageName = fullName.substring(fullName.lastIndexOf("/") + 1); It would probably be better to use the same code saveImageURL uses to guess the file name. >+ var imageNameEllipsis = Components.classes["@mozilla.org/preferences-service;1"]. >+ getService(Components.interfaces.nsIPrefBranch). >+ getComplexValue("intl.ellipsis", >+ Components.interfaces.nsIPrefLocalizedString).data; You don't need to call this imageNameEllipsis, just ellipsis will do. Also, suite style is to have the . at the start of the next line, i.e. Components.classes["..."] .getService(...) .getComplexValue(...) .data; >+ var bundle = Components.classes["@mozilla.org/intl/stringbundle;1"] >+ .getService(Components.interfaces.nsIStringBundleService) >+ .createBundle("chrome://communicator/locale/contentAreaCommands.properties"); Use getStringBundle() from contentAreaUtils.js? >+ var caption; >+ if (imageName) { >+ caption = bundle.formatStringFromName("saveImageAs", [imageName], 1); >+ } else { >+ caption = bundle.GetStringFromName("saveImageAsNoFilename"); >+ } We actually already have two captions, "Save Image" and "Save Image As..." (see goSetMenuValue above) so you would need to account for this too.

(In reply to comment #51) > Except we actually show the menuitem for onLoadedImage, onStandaloneImage or > onCanvas... This seems to work for images and standalone images. On Canvas images it just says "Save Image as...", is that a problem? > This variable is out of date and only provided for backward compatibility. OK, changed it to this.mediaURL. > It would probably be better to use the same code saveImageURL uses to guess > the file name. Yes, that would probably be better but I don't understand how saveImageURL guesses the filename, sorry. > You don't need to call this imageNameEllipsis, just ellipsis will do. Also, > suite style is to have the . at the start of the next line <..> Done. > Use getStringBundle() from contentAreaUtils.js? Done. > We actually already have two captions, "Save Image" and "Save Image As..." > (see goSetMenuValue above) so you would need to account for this too. The "SaveImageTitle" caption was identical to "saveImageAsNoFilename", so I removed the latter. I also added back the ellipsis to "Save Image ()".

(In reply to comment #52) > (In reply to comment #51) > > Except we actually show the menuitem for onLoadedImage, onStandaloneImage or > > onCanvas... > This seems to work for images and standalone images. Ah, I didn't realise it worked for standalone images too. > > It would probably be better to use the same code saveImageURL uses to guess > > the file name. > Yes, that would probably be better but I don't understand how saveImageURL > guesses the filename, sorry. Well, eventually it calls getDefaultFileName(null, uri, null, disposition) - URI you already know how to make and disposition can copy saveImageURL code.

Comment on attachment 386381 [details] [diff] [review] patch v4 >+ if (fullName.lastIndexOf("filename=") != -1) >+ var imageName = fullName.substring(fullName.lastIndexOf("filename=") + 9) >+ else >+ var imageName = fullName.substring(fullName.lastIndexOf("/") + 1); Nit: shouldn't repeat "var" for the same variable. (It used to be a strict JS warning but sadly someone got sick of the warning because it also applied to reuse of the same variable name in logically distinct blocks.) >+ if (imageName.length > 20) { >+ imageName = imageName.substr(0, 19); >+ imageName += ellipsis; >+ } Nit: the } lines up with the if >+ caption += ellipsis; This depend on the this.autoDownload preference: false means "Save Image (cheese.jpg)..." while true means "Save Image (cheese.jpg)" (which is why it is important that it's actually going to be named cheese.jpg when it saves!) >+ saveImageMenuItem.setAttribute( "label", caption ); Don't overwrite the caption if we don't have a filename. In this case we want to keep the default caption that's also used for canvas. (This default depends on whether the autoDownload pref is set.)

If you don't think you can get the correct autoDownload filename then maybe you should only show the suggested filename in the manual download case.

I tend to VERIFY the WONTFIX for this one. Data (image name) should not be displayed in the menu. As attachment 107738 [details] shows, the wanted file name on the right of View Image is crippled. I don't see a need for this incomplete information. Users can View the image and then copy the complete name from the Location Bar. Or even simpler they copy the image location into the clipboard and check and edit the name in the target application.

Let's see. Right-click an image to read its filename from the context menu: one mouse-click. Compare with this: > Users can View the image and then copy the complete name from the > Location Bar. Three clicks, including the Back button to return to the page you were reading. And this: > Or even simpler they copy the image location into the clipboard and > check and edit the name in the target application. Three clicks PLUS whatever it takes to open your chosen text editor so you'll have somewhere to paste the URL. How it this "even simpler" than doing View Image? (And how is "View Image" simpler than having the filename right there in the menu?) I don't see any problem with the solutions offered in the patch. Even if a particularly long filename is appreviated, that's still far better than nothing at all. And most filenames will not need to be abbreviated. This bug has 18 votes, over half a dozen duplicates, and a working patch to fix it. And 32 email addresses on the CC list (to whom I apologise for the bug-spam!) It strikes me as perverse to mark it as "WONTFIX" on grounds that there are other ways to get the information, and frankly plain wrong to say that these other ways are simpler. For what it's worth, seven years after this bug was reported I am *still* occasionally right-clicking images and expecting to see the filename in the context menu.