43834 - Open File dialog problems in Composer

Status: VERIFIED FIXED

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

Description

[Charles Manske]

There are 2 small but important dogfood issues with the Open Files dialog:
1. In Windows, you can type an arbitrary filename in the "common dialog",
but if that file doesn't exist, user gets a confusing error message about 
downloading a filetype that doesn't exist. If you use Cancel in that message,
the network code spins forever and you can't go back to the document (I'll 
file a separate bug on that issue.)
The solution is very simple - add a line to nsFilePicker code:
     if (mMode == modeOpen) {
+      // FILE MUST EXIST!
+      ofn.Flags |= OFN_FILEMUSTEXIST;
       result = ::GetOpenFileName(&ofn);
     }
With this, Windows popups up a message dialog telling user the file doesn't 
exist and forces them to enter or pick an existing file.

2. The filters for file type are "All", "HTML Files", and  "Text Files".
This is very bad for Composer, which primarily edits HTML, can allow "txt", and
not anything else. The "All" is included only for advanced users to load 
text files other than "txt". The default filter should always be "HTML Files"
Again fix is very simple: Instead of calling the single JS method
AppendFilters() with bit-flags for each desired type (and no control 
over order of filters in the combobox), change JS to use:
    if (dialog.openAppList.data == "2") // (Opening into Composer)
    {
      // When loading into Composer, direct user to prefer HTML files and text 
files:
      fp.appendFilter(fpbundle.GetStringFromName("htmlTitle"), 
fpbundle.GetStringFromName("htmlFilter"));
      fp.appendFilter(fpbundle.GetStringFromName("textTitle"), 
fpbundle.GetStringFromName("textFilter"));
      fp.appendFilter(fpbundle.GetStringFromName("allTitle"), 
fpbundle.GetStringFromName("allFilter"));
    }
Thus the filters are added in the order Composer requires. This has NO affect
on loading files into anything but Composer.
This issue is a regression from M14 code -- someone changed the JS to lump
the filter appending into one method, AppendFilters, where before we were 
doing exactly what I'm now suggesting.

Comment 1

[Charles Manske]

Important useability issue for Composer. Requesting nsbeta fix.
They are easy, safe, and already in hand.

Comment 2

[Akkana Peck]

On linux, if I type in a nonexistant pathname, I get on stdout:

JavaScript error: 
 line 0: uncaught exception: [Exception... "Component returned failure code:
0x80520001 [nsIFile.append]"  nsresult: "0x80520001 (<unknown>)"  location: "JS
frame :: chrome://global/content/filepicker.js :: onOK :: line 87"  data: no]

and the fsb just stays up as if I had never clicked OK.  It should have an error
indication shown to the user (in case the user isn't watching stdout).

As to the second problem: the filter shown by default is html files (with text
and all as two other choices in the dropdown) but in practice, all files in the
given directory are shown, so no filtering is being done.

There's a third, more serious problem: there's no scrollbar in the file area, so
it's very nonobvious how to navigate visually (you can always type in a full
pathname in the text field).  It turns out that if you click on one of the
files/directories shown (to set focus), then hit Page Down, the scrollbar will
appear, but I wouldn't expect an outside user to be able to figure that out.

Comment 3

[Jay Patel [:jay]]

Putting on [nsbeta2+][dogfood-] radar.  Does not need a fix
ASAP for daily work, but we should fix this for beta2. 

Comment 4

[Charles Manske]

I just checked the filtering in Linux and it seems to work ok, so we are
only blocked by the Mac filtering not working.

Comment 5

[R.K.Aa.]

umm..i can't open *anything* from composer..
File/Open file.. - nothing happens.
File/Open web location.. - nothing.
Currently testing build ID 2000-070520 Linux.
"Is it only me?"

Comment 6

[Charles Manske]

The last comment is a new problem, having nothing to do with this bug.
Thanks for pointing this out, however!

Comment 7

[R.K.Aa.]

the error i mentioned is on/off: sometimes it works, it seems - and sometimes
after many attempts. Shall i file a new bug on this?

Comment 8

[rubydoo123]

added fix by date in status

Comment 9

[Charles Manske]

The Mac problem with filters is covered by bug 43932, which, IMHO, should be
nsbeta2+, but I guess nobody cares about Mac.
Windows and Linux filters now work, so marking this fixed.

Comment 10

[sujay]

verified in 7/12 build.