21515 - [FEATURE] Context menu should have filename after `Save Image ...'

Status: VERIFIED DUPLICATE of bug 136110

(SeaMonkey :: UI Design, enhancement, P2)

Description

[chuckie]

Having the filename shown in the context menu can very often be very useful.

Comment 1

[chuckie]

Clarification:
That is, the context menu when you right-click on an Image.

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Moving this to UE/UI component and reassigning for consideration and appropriate
reassignment...

Comment 3

[shuang (gone)]

reassign it to german to make final call in design.

Comment 4

[sairuh (rarely reading bugmail)]

spam: reassigning QA contact to self.

Comment 5

[Joseph Elwell]

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

Comment 6

[leger]

Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.

Comment 7

[:deanis74]

Either this is a duplicate of 24214 or vice versa.

Comment 8

[sairuh (rarely reading bugmail)]

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

Comment 9

[Sebastian Späth]

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

Comment 10

[jglick]

Yes, name of image should appear in parenthesis after "View Image ( <name> )"

Please reassign to correct engineer to implement.

Comment 11

[jglick]

Please assign to correct engineer to be implemented.

Comment 12

[sairuh (rarely reading bugmail)]

communicator 4.x already has this...why must we wait till post-6.0 to implement
this? sounds like a step backwards, imho.

Comment 13

[don]

Put this on the PDT radar for beta 2 ...

(Bill, don't panic.)

Comment 14

[leger]

Putting on [nsbeta2-] radar. Not critical to beta2.  Adding nsbeta3 keyword.

Comment 15

[don]

Move to M20 target milestone.

Comment 16

[Matthew T (active 1999-2002)]

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.

Comment 17

[:deanis74]

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.

Comment 18

[chuckie]

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.

Comment 19

[Bill Law]

> 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?

Comment 20

[chuckie]

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.

Comment 21

[leger]

Removing self from cc. Will catch in nsbeta3 reviews in future.

Comment 22

[Bill Law]

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).

Comment 23

[mw]

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.

Comment 24

[Alan]

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?

Comment 25

[mw]

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.

Comment 26

[Matthew T (active 1999-2002)]

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.

Comment 27

[Bill Law]

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...

Comment 28

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 29

[johng]

nav triage team:
nsbeta3-

Comment 30

[Matthew T (active 1999-2002)]

Seems like an obvious candidate for helpwanted -- small problem, low risk, geek 
feature. :-) Also resummarizing (see my comments on 2000-06-14).

Comment 31

[James Cooper]

Dunno what the final decision on this one is, but since I really like this
feature, as both a sometime HTMLer and a regular user, I decided to go ahead and
implement it today and learn XUL in the process. Turns out it's not that hard
(although finding good Javascript documentation is.)

I've got it showing the full URL next to View Image, which isn't quite what's
been requested, but that's simply a matter of finding an existing URL truncation
function in Mozilla or writing one if none exists. I'll troll around in the
newsgroups and the code for a while to see what's around (unless someone here
knows and would like to save me some time.)

Anyway, the change as it stands now is thus:
in mozilla/bin/chrome/packages/core/navigator/content/navigator.xul
replace
-        oncreate="contextMenu = new nsContextMenu( this );"
with
+        oncreate="contextMenu = new nsContextMenu( this ); viewimg =
document.getElementById('context-viewimage');
viewimg.setAttribute('value','&viewImageCmd.label; (' + contextMenu.imageURL +
')' );"

Pretty easy, huh? I know it's not pretty, but it turns out that passing
Javascript-generated strings to XUL properties isn't directly possible (that I
know of) but this seems to work well. Like i said, it's not done yet, lacking
URL truncation, but that'll happen Real Soon Now.

I also don't know if it's a good idea to factor this out into nsContextMenu.js
or not. My instinct is not to due to code proximity, but neatness is also a
factor. Any suggestions?

Comment 32

[James Cooper]

Works like a charm now. It took all of five minutes to get the last bit in
place. The filename extracting code is downright trivial.

The final (and very safe) form, unless some refactoring is possible/desired (or
there's a better way to do it), in hand-diff:
in mozilla/bin/chrome/packages/core/navigator/content/navigator.xul
-        oncreate="contextMenu = new nsContextMenu( this );"
+        oncreate="contextMenu = new nsContextMenu( this );
+                 viewimg = document.getElementById('context-viewimage');
+                 viewimg.setAttribute('value','&viewImageCmd.label; ('
+                              + fileNameOf( contextMenu.imageURL ) + ')' );"

and in mozilla/bin/chrome/packages/core/navigator/content/nsContextMenu.js
-// Prototype for nsContextMenu "class."
+function fileNameOf( urlstr ) {
+    return urlstr.slice( urlstr.lastIndexOf( "/" ) + 1 );
+}
+
+// Prototype for nsContextMenu "class."

What happens if there are no slashes? Just returns the whole string. Javascript
is yummy.

Problems: long file names get ellipses that cut off the end, but that's an
XPWidget problem, I think. Too-long-string handling in general, at least.

I put it on View Image rather than Save Image As... because
1- That's where NN4.x has it.
2- It makes at least as much sense as Save Image As... and allows for more
characters before truncation.
3- It just looks better. It's in the middle of the box, and doesn't clash with
the ellipsis.

Others are free to disagree.

Anyway, this is a real easy and safe fix. Can probably be slipped in before
nsbeta2/m17 with little difficulty.

Comment 33

[Arnoud Berendsen]

Please please please get this feature in as soon as possible! I've soo missed 
you, filename! :)

Comment 34

[Doron Rosenberg (IBM)]

anyone want to review this? This would be neat to have in nsbeta3/m18.

Comment 35

[Arnoud Berendsen]

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

Comment 36

[Asa Dotzler [:asa]]

um, not likely :)

Comment 37

[Arnoud Berendsen]

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?

Comment 38

[timeless]

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.

Comment 39

[timeless]

Attachment: Proposed patch to nsContextMenu.js adds file name to view image

Comment 40

[Matthew T (active 1999-2002)]

> 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.

Comment 41

[Stephen Ostermiller]

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?

Comment 42

[:deanis74]

Yes.

Comment 43

[Matthew T (active 1999-2002)]

Showing the domain which an image came from could be achieved by bug 33576, 
without obfuscating the image context menu for ordinary users.

Comment 44

[Mats Palmgren (inactive)]

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

Comment 45

[Doron Rosenberg (IBM)]

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

Comment 46

[Doron Rosenberg (IBM)]

Attachment: new patch

Comment 47

[Doron Rosenberg (IBM)]

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).

Comment 48

[Doron Rosenberg (IBM)]

*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

Comment 49

[Doron Rosenberg (IBM)]

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 ;)

Comment 50

[Mats Palmgren (inactive)]

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

Comment 51

[Doron Rosenberg (IBM)]

*cough* anything left to do here?

Comment 52

[Doron Rosenberg (IBM)]

Attachment: new patch

Comment 53

[Doron Rosenberg (IBM)]

added patch, removes a useless entity (save image as...), as it is retrieved
from the stringbundle 

Comment 54

[Doron Rosenberg (IBM)]

Attachment: improved patch (tab issue)

Comment 55

[Boris Zbarsky [:bzbarsky]]

r=bzbarsky for the latest patch

Comment 56

[Doron Rosenberg (IBM)]

ccing [e-mail] for a sr= if possible

Comment 57

[Alec Flett]

no! please use nsIStringBundle.formatStringFromName() to format this string,
instead of using the s/// operator.

Comment 58

[Doron Rosenberg (IBM)]

Attachment: even newer patch

Comment 59

[Doron Rosenberg (IBM)]

new patch with suggested changes, thanks for alecf for answering my questions
regarding that

Comment 60

[Alec Flett]

looks great. sr=alecf

Comment 61

[Blake Ross]

fix is in.

Comment 62

[Jure Repinc (JLP)]

Verifying

Comment 63

[Blake Ross]

Bugs are verified on all platforms against which they're reported, and this 
information is given.

Comment 64

[Blake Ross]

fixed.

Comment 65

[:deanis74]

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.

Comment 66

[sairuh (rarely reading bugmail)]

dean, i agree with you there... doron, should this be reopened, or shall i file
another bug re: truncating long names mo' bettah? thx...

Comment 67

[timeless]

File a new bug. Mark this one as blocking that one. Thx

Verify based on comments by dean and se.

Comment 68

[Doron Rosenberg (IBM)]

file a new one. currently classic will not cut it of btw, that is a known bug in
the classic theme.

Comment 69

[sairuh (rarely reading bugmail)]

done! filed bug 66555.

Comment 70

[Doron Rosenberg (IBM)]

added 66683 - messes up in non-navigator sidebars, argh

Comment 71

[:deanis74]

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?

Comment 72

[Mauricio Collares [:collares]]

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

Comment 73

[Mauricio Collares [:collares]]

new menus don't show image filename after 'Save Image ...'. Reopening.

Comment 74

[Doron Rosenberg (IBM)]

You best open a new bug on UI Design, as this was removed in the latest spec

Comment 75

[Alfonso Martinez]

bug 136110 is gonna take care of adding back the filename, so marking this one
fixed again.

Comment 76

[Lorenzo Colitti]

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.

Comment 77

[Mats Palmgren (inactive)]

*** This bug has been marked as a duplicate of 136110 ***

Comment 78

[sairuh (rarely reading bugmail)]

mass-verification of Duplicates.

mail search string for bugspam: SolarFlaresAreTheCause