24731 - Linux: OK button should do nothing if no file is selected

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[(not reading, please use [e-mail] instead)]

go to a message with an attachment, and try to save the attachment.

when you get the native gtk file picker, click on a directory, and note that the
file name gets reset to blank.

hit ok.

it will close the window, and you'll get an error to the console:

user hit ok
JavaScript Error: uncaught exception: [Exception... "Component returned failure
code: 0x80004004 (NS_ERROR_ABORT) [nsIMessenger.openAttachment]"  nsresult:
"0x80004004 (NS_ERROR_ABORT)"  location: "JS frame ::
chrome://messenger/content/msgHdrViewOverlay.js :: OpenAttachURL :: line 193" 
data: no]   

instead, the file picker should not close when the user hits ok if the text area
(the name of the selected file) was blank.

Comment 1

[Alec Flett]

I really do think this is a dupe of bug 24719

Comment 2

[Stuart Parmenter]

ok button when no file is selected on OPEN returns the directory.  on SAVE it 
just returns error and doesn't do anything.  if you click ok with no file name, 
i personally think you should be beat over the head with a cancel button... :)

Comment 3

[Alec Flett]

yeah, but when you hit the enter key, it's just like hitting ok. and I should be
able to hit enter to enter a directory. try xmms, it does the right thing.

Comment 4

[Stuart Parmenter]

ok, this is fixed with the new file picker... the new file picker isn't on
everywhere, but it is in some places... if your favorite place isn't using the
new file picker, you should make it use it :)

Comment 5

[(not reading, please use [e-mail] instead)]

I've opened bug #34051 to track and fix the use of nsIFileSpecWithUI (and use 
nsIFilePicker)

when will nsIFileSpecWithUI be depricated?

Comment 6

[(not reading, please use [e-mail] instead)]

#34051 only is for *mailnews* uses of nsIFileSpecWithUI.

Comment 7

[fenella]

On Mac and Win32, Click on OK button does nothing when no file is selected. This
is observed in builds Mac (2000-04-21-08 M16) and Win32 (2000-04-21-09 M16).

However, on Linux (2000-04-21-08 M16), hitting on OK button when no file is
selected close the attachment dialog and it shows the directory path in the 
Compose window.
View the received message, it shows an attachment file called attachment.txt and
this file is 0 bytes.

Reopen this bug for Linux only.

Comment 8

[Stuart Parmenter]

This is fixed with nsIFilePicker.  People should not be using nsFileSpecWithUI
or nsIFileWidget anymore.  See 34051 for mailnews tracking of these changes.

Comment 9

[laurel]

I'm confused here... is this bug tracking the fix for the original description
only, i.e. the save single attachment file picker?  Fenella's comments are for
attaching files in the compose window.

Here's what happens using 2000-06-01-08 commercial build, linux rh6.0:
1.   Save individual attachment:  when no file name present and OK, dailog
closes.  Does not save attachment, though.
     Question: Need to reopen bug  because we don't want dialog to close on OK
if filename blank?

2.   Save all attachments:  OK saves all attachments, doesn't use the Open or
Save to disk dialog, goes right to  generic file picker.
     Question: is this OK and if not, do we want to track here or track
elsewhere?

3.   Attach file from compose window:  still does exactly what fenella states in
her last comments.  OK closes dialog and inserts directory name in the
attachment pane in compose window.
     Question:  Do we track this issue here or elsewhere?

Comment 10

[laurel]

.

Comment 11

[Stuart Parmenter]

more gifts for bryner

Comment 12

[Brian Ryner (not reading)]

Clearing target milestone.

Comment 13

[Brian Ryner (not reading)]

On today's build, I tried attaching a file, leaving the file name field blank,
and clicking OK.  The file picker window stayed open, as it should.  Can we
close this bug or are there other cases where we still don't do the right thing?

Comment 14

[Brian Ryner (not reading)]

Based on the original description, I'm marking this fixed.

Comment 15

[laurel]

Well, will reopen for comments...
Using sept7 commercial build linux rh6.0, I see no exception noted in the
console, just "user hit ok". The save file dialog does indeed close upon OK when
text field is blank due to directory selection or user intentionally clearing
the text. No file is saved to the directory, the dialog just closes on OK.

Comment 16

[Brian Ryner (not reading)]

Jag offered to look at this.

Comment 17

[Peter "jag" Annema]

Got a fix for this in my tree, I'll attach it later today.

Comment 18

[Peter "jag" Annema]

Marking this depend on 52188 (disable that button when no file is selected).
Okay, so my days have odd lengths ;-)

Comment 19

[Peter "jag" Annema]

To answer laurel's questions:

1) With 52188 fixed, clicking OK on nothing selected won't work, since it's disabled.

2) I guess for consistency, save all should have an open all version, new bug.

3) This too is fixed with 52188 I believe.

I will test 1 and 3 later today, but if someone wants to beat me to it, feel free ;-)

Comment 20

[Peter "jag" Annema]

laurel, cases 1 and 3 now work as expected, marking this one fixed. Could you
open a new bug for case 2 (have Open All as well as Save All)?

Comment 21

[laurel]

OK using oct20 branch commercial build, linux rh6.0.