If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

VERIFIED DUPLICATE of bug 136110

Status

SeaMonkey
UI Design
P2
enhancement
VERIFIED DUPLICATE of bug 136110
18 years ago
9 years ago

People

(Reporter: chuckie, Assigned: Doron Rosenberg (IBM))

Tracking

Trunk
mozilla0.9
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

18 years ago
Having the filename shown in the context menu can very often be very useful.
(Reporter)

Comment 1

18 years ago
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...

Updated

18 years ago
Assignee: shuang → german

Comment 3

18 years ago
reassign it to german to make final call in design.
QA Contact: leger → sairuh
spam: reassigning QA contact to self.

Comment 5

18 years ago
*** Bug 24477 has been marked as a duplicate of this bug. ***
Depends on: 23567

Comment 6

18 years ago
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

Comment 7

18 years ago
Either this is a duplicate of 24214 or vice versa.
*** Bug 24214 has been marked as a duplicate of this bug. ***

Comment 9

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

Comment 10

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

Please reassign to correct engineer to implement.

Comment 11

18 years ago
Please assign to correct engineer to be implemented.
Assignee: german → don

Updated

18 years ago
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 → ---

Comment 13

18 years ago
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

Comment 14

18 years ago
Putting on [nsbeta2-] radar. Not critical to beta2.  Adding nsbeta3 keyword.
Keywords: nsbeta3
Whiteboard: [nsbeta2-]

Comment 15

18 years ago
Move to M20 target milestone.
Target Milestone: M17 → M20

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 16

18 years ago
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

18 years ago
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.
(Reporter)

Comment 18

18 years ago
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

18 years ago
> 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?
(Reporter)

Comment 20

18 years ago
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

18 years ago
Removing self from cc. Will catch in nsbeta3 reviews in future.

Comment 22

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
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. ***

Comment 29

17 years ago
nav triage team:
nsbeta3-
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]

Comment 30

17 years ago
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 ...'

Comment 31

17 years ago
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

17 years ago
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.
Keywords: patch, review

Comment 33

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

Comment 34

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

Comment 35

17 years ago
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

17 years ago
um, not likely :)

Comment 37

17 years ago
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

17 years ago
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
Keywords: helpwanted, nsbeta2, nsbeta3
Whiteboard: [nsbeta2-][nsbeta3-]
Target Milestone: M20 → mozilla0.9

Comment 39

17 years ago
Created attachment 19221 [details] [diff] [review]
Proposed patch to nsContextMenu.js adds file name to view image

Comment 40

17 years ago
> 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

17 years ago
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

17 years ago
Yes.

Comment 43

17 years ago
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. ***
(Assignee)

Comment 45

17 years ago
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
(Assignee)

Comment 46

17 years ago
Created attachment 21288 [details] [diff] [review]
new patch
(Assignee)

Comment 47

17 years ago
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).
(Assignee)

Comment 48

17 years ago
*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
(Assignee)

Comment 49

17 years ago
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. ***
(Assignee)

Comment 51

17 years ago
*cough* anything left to do here?
(Assignee)

Comment 52

17 years ago
Created attachment 23175 [details] [diff] [review]
new patch
(Assignee)

Comment 53

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

Comment 54

17 years ago
Created attachment 23181 [details] [diff] [review]
improved patch (tab issue)
r=bzbarsky for the latest patch
(Assignee)

Comment 56

17 years ago
ccing alecf@netscape.com for a sr= if possible

Status: NEW → ASSIGNED

Comment 57

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

Comment 58

17 years ago
Created attachment 23301 [details] [diff] [review]
even newer patch
(Assignee)

Comment 59

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

Comment 60

17 years ago
looks great. sr=alecf

Comment 61

17 years ago
fix is in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 62

17 years ago
Verifying
Status: RESOLVED → VERIFIED

Comment 63

17 years ago
Bugs are verified on all platforms against which they're reported, and this 
information is given.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 64

17 years ago
fixed.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 65

17 years ago
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...

Comment 67

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

Verify based on comments by dean and se.
Status: RESOLVED → VERIFIED
(Assignee)

Comment 68

17 years ago
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
(Assignee)

Comment 70

17 years ago
added 66683 - messes up in non-navigator sidebars, argh

Comment 71

17 years ago
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 → ---
(Assignee)

Comment 74

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

Comment 75

15 years ago
bug 136110 is gonna take care of adding back the filename, so marking this one
fixed again.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago15 years ago
Resolution: --- → FIXED

Comment 76

15 years ago
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
Last Resolved: 15 years ago15 years ago
Resolution: --- → DUPLICATE
mass-verification of Duplicates.

mail search string for bugspam: SolarFlaresAreTheCause
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite

Updated

9 years ago
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.