41085 - (insert) image dialog should offer *.* as a file type choice.

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[Patrick]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m16) Gecko/20000530
BuildID:    2000053020

In composer, after choosing insert, image, and then choosing file, under the
second drop down box (image types), there should be the option *.* (IMHO).

Reproducible: Always
Steps to Reproduce:
1.Click insert image
2.Click choose file
3.Click files of type drop down menu


Actual Results:  You only get one choice.

Expected Results:  Should be AT LEAST two, *.*, and image types, would be better
if it was a long list of potential file types.

I see this on Windows98se, build 2000053020. I havent tested other platforms for
the problem yet.

Comment 1

[rubydoo123]

assigning to cmanske
I would think we would want these choices:
.gif
.jpg
.png
All Files

Comment 2

[Charles Manske]

I don't know who changed the filter to show just "Image Files", but it should
include the list of acceptable file types, as stated by Beth: *.gif, *.jpg, 
and *.png. These are the only acceptable types. I do NOT think we should
include *.* as that would only result in broken images if user tried to insert
them. Obviously we will add other file types as we support converting -- 
e.g., bmp to png or jpg.

Comment 3

[Charles Manske]

The image types supported are: gif, jpeg, and png. That is what the "Image 
Files" filter allows. We don't want to encourage other types as the result only
in broken images now. A user can simply put "*.*" in the file editbox (in
Windows, anyway) if they want to see other file types.

Comment 4

[Charles Manske]

resolving this.

Comment 5

[timeless]

reopen.

Comment 6

[timeless]

reassign.

Comment 7

[Charles Manske]

Who said you can reopen this?
I do not think we should add "*.*"

Comment 8

[Charles Manske]

Remember that if someone wants to change this, they have to get permission from
an editor module owner.

Comment 9

[Matthew T (active 1999-2002)]

Timeless, if you're going to reopen a bug, you should really give a good 
reason. Here's four of them:

(1) When some new image format comes into popularity five years from now (like
    PNG did in the last five), my 2001-vintage copy of Navigator won't prohibit
    me from viewing it -- I'll be able to use a plugin (like I did for PNGs in
    4.x). So why will my 2001-vintage copy of Composer prohibit me from
    inserting it? I shouldn't have to download a whole new version of Mozilla,
    just to allow insertion of pictures of types other than those in Mozilla's
    out-of-date list.

(2) Other apps on Windows (word processors, image editors, etc) almost
    invariably include an `All Files' filter in their Open/Insert filepickers,
    just in case their selection of filters does not encompass all the file
    types which can be opened. (A file might have a suffix which does not match
    its type, for example; or if it's intended for a Web site where URLs aren't
    supposed to have suffixes, like the new mozilla.org site for example, the
    file might not have a suffix at all.)

(3) Loss of reversibility. Composer will let me open an existing file which
    contains the code <img src="face.xbm" />. That's perfectly valid code. If I
    remove that image from the page, and then decide (too late for `Undo') that
    I actually do want it there, I'll have to use a program other than Composer
    to put it back. How annoying.

(4) If I insert an image of a type not currently supported by Mozilla, it'll
    appear as a broken image icon in the Composer document. So it'll be pretty
    dang obvious that it probably won't work in other contemporary browsers
    either, without Composer having to prevent me from including it at all.

--> Editor, nobody/helpwanted for obvious reasons.

Comment 10

[Charles Manske]

Taking back bug

Comment 11

[Charles Manske]

Attachment: Add "*.*"

Comment 12

[Charles Manske]

Matthew: Why don't you have a mozilla account to help fix UI bugs?

Comment 13

[timeless]

r=timeless
sorry mathew, persuasion isn't my strong suit.
cmanske: thanks, and fwiw iirc mpt prefers not to get involved in the 
development

Comment 14

[Matthew T (active 1999-2002)]

cmanske: I'd love to, but (a) Mac development tools cost lots of money, (b) 
LinuxPPC CDs are hard to find in NZ, (c) I have too much UI design work to do 
already, and (d) the Mozilla project (IMO) lacks coherent UI design even more 
than it lacks code contributions.

In the absence of kin, sfraser, or brendan in #mozilla, I got
sr=[e-mail]. Is that ok?

Comment 15

[Charles Manske]

Thanks, Matthew and Ben

Comment 16

[Charles Manske]

checked in

Comment 17

[James Baxter]

Tested against 8-21 Build