241451 - Attach dialog's OK button reads "Open" rather than "Attach"

Status: NEW

(Thunderbird :: Message Compose Window, enhancement)

Description

[James Ascroft-Leigh]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040405 Firefox/0.8
Build Identifier: Mozilla Thunderbird 0.5 (20040207)

When attaching a document to a message being composed the standard Microsoft
Windows open file dialogue box seems to be used.  The default button - that
results in the selected document being attached - has the misleading label
"Open".  This confused my Dad for a while because he did not wish to open the
document (in this case using Microsoft Word).

If possible this dialogue should be modified to have the default button labelled
"Attach" or something similar.  Otherwise an alternative dialogue should be
sought.  There may be an issue when a folder is selected in which case the
caption "Open" is appropriate and "Attach" would not be.

Reproducible: Always
Steps to Reproduce:

Comment 1

[WADA:World Anti-bad-Duping Agency]

I can imagine you Dad's embarassment ;-)
I do not like MS's dialogs too.

Workaround: Teach your Dad "Drag & Drop" way, which was borrowed from Mac.

Comment 2

[Mike Cowperthwaite]

Seamonkey bug 23470.

Comment 3

[Christian Krause]

I've created a patch (at least for the gtk2 toolkit) which solves the problem.
see #23470

To reduce the amount of duplicate bugs, it would be nice if this one could be
resolved as dupe of #23470.

Comment 4

[Mike Cowperthwaite]

(In reply to comment #3)
> To reduce the amount of duplicate bugs, it would be nice if this one could be
> resolved as dupe of #23470.

Does your patch apply to both the suite and to Thunderbird?

Comment 5

[Christian Krause]

(In reply to comment #4)
> (In reply to comment #3)
> > To reduce the amount of duplicate bugs, it would be nice if this one could be
> > resolved as dupe of #23470.

Ok, I see. This bug is for thunderbird and the other is for the mozilla suite.

> Does your patch apply to both the suite and to Thunderbird?

No, it doesn't. But I'll have a look at thunderbird in the next days as well.

Comment 6

[Christian Krause]

Attachment: patch renames the "Open" button to "Attach"

Here is a small patch which solves the problem. It is slightly different from
the patch of #23470, because
"mozilla/mail/components/compose/content/MsgComposeCommands.js" has to be
patched as well.

This path is only a hack which works for gtk2 toolkit only.

Comment 7

[Christian Krause]

@mozilla bug team:

IMHO the following changes to bug should be made:
Hardware -> All
UNCORFIRMED -> NEW
OS -> All

Comment 8

[:aceman]

Is this still relevant?
Does this patch still apply to current TB codebase (TB7-8-9)? 
If yes, you need to request review for the patch from somebody responsible for this component. See https://wiki.mozilla.org/Modules/Thunderbird .

Comment 11

[Thomas D. (:thomas8)]

From duplicate bug 699382, comment 4: 

Google seems to find a number of ways how the button caption can be tweaked (it's non-trivial, for sure).

I don't know which (if any) of these documents actually apply in our case, but here's a random selection of docs which may or may not be relevant:

1) http://msdn.microsoft.com/en-us/library/microsoft.win32.filedialog.aspx
2) http://www.bcbj.org/articles/vol3/9912/Changing_common_dialog_button_captions.htm
3) http://www.codeproject.com/KB/dialog/OpenFileDialogEx.aspx
4) http://msdn.microsoft.com/en-us/library/cc138540.aspx#Y1140

2) looks temptingly simple, but then 1) shows that OnShow Event is not available in the default OpenFileDialog. But maybe it can be created, similar to how it's created in 4).

Comment 12

[:aceman]

I can try to unbitrot this, but notice it is only for Linux/GTK2.

It looks like it defines a new Filepicker mode in toolkit and then uses it in mailnews. Mailnews call filepicker with this new mode. GTK2 would know how to handle it. But the other OS widgets could have problem.

Note I can't compile/test any patch on Windows.

As a temporary workaround I could try to alias AttachMode to OpenMode (so the other OSes handle them the same (as Open)) so there is no visible change on the other OSes. Only Gtk would benefit from this patch, but all of them would work.

I'll do that for now.

Comment 13

[Jim Porter (:squib)]

I think we should really just abandon the attached patch. First, it adds invalid enum values (GTK_FILE_CHOOSER_ACTION_ATTACH, which is *not* a GTK-defined value - all the others are), and Second, I think it would make more sense to supply an optional string to nsIFilePicker.init that specifies what the button should say. That way, we can fix other related bugs, like the "save multiple messages" dialog saying "Open" under GTK. I'm sure other platforms have similar issues as well.

Comment 14

[:aceman]

Do you mean adding a new argument to nsIFilePicker.init that would only be used if the 3rd argument is set to some new special value (nsIFilePicker.modeCustom)? How can I define it to be optional?

The problem is in that case the other widgets except GTK2 would now know how to handle it (until somebody implements the changes needed for them). Or would they use the 3rd argument, which would not be modeCustom, but one of the 3 existing modes that best matches the new string (like it is done today)?

Comment 15

[Jim Porter (:squib)]

(In reply to :aceman from comment #14)
> Do you mean adding a new argument to nsIFilePicker.init that would only be
> used if the 3rd argument is set to some new special value
> (nsIFilePicker.modeCustom)? How can I define it to be optional?

Like so: http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/mime/nsIMIMEInfo.idl#123

> The problem is in that case the other widgets except GTK2 would now know how
> to handle it (until somebody implements the changes needed for them).

I doubt Firefox/Toolkit devs would accept a patch for this that doesn't work on all platforms (I know I wouldn't).

> Or would they use the 3rd argument, which would not be modeCustom, but one of
> the 3 existing modes that best matches the new string (like it is done
> today)?

There shouldn't be any reason to add new modes for the picker. Just use the existing ones and if a non-empty string is passed in for the button text, use that instead.

Anyway, this is easy enough to fix on Windows (note that you'd need to fix the file picker and the folder picker):
* XP: http://www.bcbj.org/articles/vol3/9912/Changing_common_dialog_button_captions.htm
* Vista/7: http://msdn.microsoft.com/en-us/library/windows/desktop/bb775926%28v=vs.85%29.aspx

I haven't the foggiest idea how to do it on OS/X, but perhaps there are toolkit devs who'd know.

Comment 16

[:aceman]

(In reply to Jim Porter (:squib) from comment #15)
> (In reply to :aceman from comment #14)
> > Do you mean adding a new argument to nsIFilePicker.init that would only be
> > used if the 3rd argument is set to some new special value
> > (nsIFilePicker.modeCustom)? How can I define it to be optional?
> 
> Like so:
> http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/mime/nsIMIMEInfo.
> idl#123

It doesn't look much optional. All the callers (like 
content/html/content/src/nsHTMLInputElement.cpp:300) still require it.

Comment 17

[Jim Porter (:squib)]

C++ callers can't take advantage of [optional] parameters.

Comment 18

[:aceman]

That's why I asked first:)
So that would be quite invasive change for nothing. All platforms would be unchanged, only GTK2 would profit from the patch. You are right that nobody would accept that. I wanted to make the argument optional so that no callers need to be changed, only the Mailnews spots, and we could at least test it on gtk2.

Comment 19

[James Ascroft-Leigh]

I have updated the bug to reflect that this was originally observed on Microsoft Windows.  I have not tested other platforms to see if the issue is more widespread.  Thanks to everyone who has spent time on this.  My Dad is still using Thunderbird for email almost 7 years on from the original bug report :)  Clearly this mild usability glitch isn't fundamental.

Comment 20

[Jim Porter (:squib)]

(In reply to James Ascroft-Leigh from comment #19)
> I have updated the bug to reflect that this was originally observed on
> Microsoft Windows.

Please don't. This applies to all platforms.

Comment 21

[Adrian Alcaraz]

Attachment: same problem

Thanks from quotorgeme1975.