spun off from bug 21515. thx to dean for pointing this out. if the image file has a long name, we currently truncate it as "Save Image (long_long_long..." instead of "Save Image (long_long_lo...name.gif)". we should do the latter.

doron, you wanna take this one...?

--> me. i have a patch, just need to know, how much should we cut off? ns4 win98 does this: [10]...[6].ext

Sounds OK to me.

actually, i rechecked stuff and what i'm seeing is (filename.gif)... where the ellipses follow the whole filename. {eg, the banner on http://mozilla.org/] would that be yet another bug? or does that pertain to this one?

argh, disregard my comment re: the ellipses. of course they should be there, since a dialog would follow after selection. doh! anyhow, i'm gonna attach a test image file with a long name.

Doron, sorry, not trying to make this even more complicated, but... Instead of a predetermined number of characters before and after the ellipsis, how hard would it be to calculate the width of the characters to display, and always make sure the name doesn't exceed a certain width? Though perhaps a minimum number of characters should always be displayed no matter what.

Is it possible to determine the width of the context menu? Even then, we need a maximum width. I am going to play more around with ns4 and see what it does

cc mpt in case there is a spec on this

A spec? For this? Hahahaha... ahem. Doron, don't give any special treatment to the suffix -- a picture doesn't necessarily have one. Just {up to 10 characters}...{up to 10 characters}.

yea, i currenty do [10]...[6] a lot of capital letters will mess any more than that, since we are not using unispace (um, where each character takes the same width, forgot how that is called).

i'll attach my patch tomorrow, still playing with the numbers.

[10]...[6] fails with image names containing a lot of capital letters, so this is more complex.

Doron, this is why I suggested calculating the width and capping the filename based on some sort of max width. Then it won't matter what kind of characters are in the filename.

I think as long as the .extension is preserved and has a few letters before that extension (up to like 6) and a few letters from the beginning of the word (up to like 10) you should be fine. what do you mean by failing?

by failing i meant there is overflow and the last bit of the name becomes "...". A image with just capital letters can overflow after 6 characters showing in modern for example. Probably a good idea is to have a loop until no overflow occurs and keepign taking a character away from the center or such. If anyone has any idea how to check if a menuitem overflows in js...

i have a evil temp fix - make the imagename lowercase! /me ducks

-> 1.0 There is still some overflow issues, now only with classic and images with capital letters (AWWWWWWWWWWW.jpg for example). So this is going to take more time, especially since Ben says there is no simple js way to check for overflow in a menuitem.

ok, i added a patch which will do it for most cases. The only case is the aforementioned case of capital letters in the imagename. Also, this seems to only happen in classic, modern's contextmenus are more flexible it seems. So unless anyone knows of a way to check if a menuitem is overflowing, I suggest this for a temp fix.

Looks good to me as a temp fix... r=bzbarsky@mit.edu

Is endBit long enough? For filenames with an 3-character extension, that's the last character of the filename then .extension.

the last 5 chars are taken, so it would bee "x.foo" for example as endbit.

That's what I said, just not too clearly! I was just wondering if this was enough info.

See also bug #52978.

Yeah, I was going to mention that (!). r=dean_tessman@hotmail.com

cc: alecf for a possible sr= I'm looking at to why modern handles this better (it lets the context menu grow) while classic causes overflow pretty quickly.

so we don't know how classic does this? seems like they must set a maximum width on the menu or something? Anyway, I think this patch is hacky, I'd like further investigation on classic first.

ok, i found the css that makes classic's menu less wide that modern. http://lxr.mozilla.org/seamonkey/source/themes/classic/global/win/menu.css#66 Modern has http://lxr.mozilla.org/seamonkey/source/themes/modern/global/menu.css#198 so we can change classic's max-width then. However, I still think we should truncate the imagename. Any opinions?

Yes, no matter what we need to truncate. But if we change the max width then we should be able to push this out to around 25 characters instead of 15.

I really think we should leave it up to the theme to decide when (or if) to truncate.

hmm, the problem is, it won't truncate "neatly" (ie, cuts off at the end, not in the middle). But that is anothing issue probably...

This is very ugly for very long imagenames, the context menu grows to almost hal fo the screen width. I think that we should increase the classic width to be like modern and then do a name truncation after say 25. Any opinions?

For the truncating on the right instead of the middle, can the crop for menus be set to center, similar to how it's (going to be?) done for the bookmarks window? The cropping is handled in nsTextBoxFrame.cpp, so it should be possible for this to take effect.

What should this bug's status be? I notice in the latest builds that the filename is no longer displayed at all in the context menu. Is this intentional, or just a temporary thing?

wyoung: the new context menus that landed just before 1.0 RC1 don't include the image name in the context menu. There is a working patch for this in bug 136110, but there doesn't seem to be consensus that this feature is useful. If you would like it, please comment in bug 136110 and/or vote for that bug.

the imagename isn't needed.