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:
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.
Seamonkey bug 23470.
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.
(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?
(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.
Created attachment 187352 [details] [diff] [review] 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.
@mozilla bug team: IMHO the following changes to bug should be made: Hardware -> All UNCORFIRMED -> NEW OS -> All
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 .
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).
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.
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.
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)?
(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.
(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.
C++ callers can't take advantage of [optional] parameters.
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.
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.
(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.