Closed Bug 21515 Opened 20 years ago Closed 18 years ago

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

Categories

(SeaMonkey :: UI Design, enhancement, P2)

enhancement

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 136110
mozilla0.9

People

(Reporter: chuckie, Assigned: doronr)

References

Details

Attachments

(5 files)

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.
Assignee: leger → shuang
Component: Browser-General → UE/UI
Moving this to UE/UI component and reassigning for consideration and appropriate
reassignment...
Assignee: shuang → german
reassign it to german to make final call in design.
QA Contact: leger → sairuh
spam: reassigning QA contact to self.
*** Bug 24477 has been marked as a duplicate of this bug. ***
Depends on: 23567
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
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.
Assignee: german → don
Target Milestone: --- → Future
communicator 4.x already has this...why must we wait till post-6.0 to implement
this? sounds like a step backwards, imho.
Severity: enhancement → normal
Keywords: 4xp
Target Milestone: Future → ---
Put this on the PDT radar for beta 2 ...

(Bill, don't panic.)
Assignee: don → law
Keywords: nsbeta2
Priority: P3 → P2
Summary: Context menu should have filename after View Image → [FEATURE] Context menu should have filename after View Image
Target Milestone: --- → M17
Putting on [nsbeta2-] radar. Not critical to beta2.  Adding nsbeta3 keyword.
Keywords: nsbeta3
Whiteboard: [nsbeta2-]
Move to M20 target milestone.
Target Milestone: M17 → M20
Status: NEW → ASSIGNED
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-
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
Seems like an obvious candidate for helpwanted -- small problem, low risk, geek 
feature. :-) Also resummarizing (see my comments on 2000-06-14).
Component: User Interface: Design Feedback → XP Apps: GUI Features
Keywords: helpwanted
Summary: [FEATURE] Context menu should have filename after View Image → [FEATURE] Context menu should have filename after `Save Image ...'
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?

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.
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.
Assignee: law → timeless
Severity: normal → enhancement
Status: ASSIGNED → NEW
Whiteboard: [nsbeta2-][nsbeta3-]
Target Milestone: M20 → mozilla0.9
> 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?
Yes.
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
Attached patch new patchSplinter Review
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 ;)
Assignee: timeless → doronr
*** Bug 64481 has been marked as a duplicate of this bug. ***
*cough* anything left to do here?
Attached patch new patchSplinter Review
added patch, removes a useless entity (save image as...), as it is retrieved
from the stringbundle 
r=bzbarsky for the latest patch
ccing alecf@netscape.com for a sr= if possible

Status: NEW → ASSIGNED
no! please use nsIStringBundle.formatStringFromName() to format this string,
instead of using the s/// operator.
Attached patch even newer patchSplinter Review
new patch with suggested changes, thanks for alecf for answering my questions
regarding that
looks great. sr=alecf
fix is in.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Verifying
Status: RESOLVED → VERIFIED
Bugs are verified on all platforms against which they're reported, and this 
information is given.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
fixed.
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
file a new one. currently classic will not cut it of btw, that is a known bug in
the classic theme.
done! filed bug 66555.
Blocks: 66555
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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.
Status: REOPENED → RESOLVED
Closed: 19 years ago18 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

*** This bug has been marked as a duplicate of 136110 ***
Status: REOPENED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → DUPLICATE
mass-verification of Duplicates.

mail search string for bugspam: SolarFlaresAreTheCause
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.