990 bytes, patch
|Details | Diff | Splinter Review|
994 bytes, patch
Scott MacGregor: approval-branch-1.8.1+
|Details | Diff | Splinter Review|
extension-list is appearing twice in ldif/tab/txt import file picker spun off from bug #122282 see http://bugzilla.mozilla.org/show_bug.cgi?id=122282#c5 http://bugzilla.mozilla.org/show_bug.cgi?id=122282#c15 I'll attach pkw's patch for addressBook.properties. my problem is that the change to addressBook.properties fixes a problem on linux ("Remove the extensions from the addressbook.properties file because it causes the extensions to show up twice for builds using the nsFilepicker.js file picker (UNIX") but causes a new one on win32 ("extensions not appearing") this seems like a general problem that should happen with other users of nsFilepicker.js, or a problem with the mailnews code that we shouldn't be specifying the extensions like that.
Comment on attachment 114082 [details] [diff] [review] pkw's fix don't land this patch
Created attachment 194587 [details] [diff] [review] Updated patch I can't see why the previous patch shouldn't work on windows. This patch is an updated version. Mike: Can you test import and export address book file picker dialogs with this patch on windows and check that in the drop down you get the following entries: LDIF (*.ldi; *.ldif) Comma Separated (*.csv) Tab Delimited (*.tab; *.txt) All Files (*) Note that the (...) parts may not be there - they should be. I'm hoping that there has been a patch gone in for the windows file picker that would fix this problem. Thanks.
Note: I've had a look at a windows nightly, and the file pickers that aren't the import/export ldif/tab/txt ones and they don't display extensions. Therefore, as long as we still filter correctly, I think we should go with the new patch and if we want extensions shown on windows, then that is a file picker bug.
Comment on attachment 194587 [details] [diff] [review] Updated patch As mentioned in comment 4, in general the windows file pickers don't display *.whatever, whereas the linux ones do. In the case of importing address books, linux displays (*.ldi,*.ldif)(*.ldi,*.ldif) whereas windows displays just (*.ldi,*.ldif) This patch will make linux display the extensions just once, and windows not at all - following the current convention. If we want the windows ones to display file extensions, hten that should be a seperate bug.
Created attachment 197324 [details] [diff] [review] Thunderbird version Thunderbird version - Please see my previous comments on this bug for the effects of this patch.
Created attachment 197349 [details] [diff] [review] Real Thunderbird version I got the file wrong last time for the Thunderbird version (mailnews/addrbook/resources/locale/en-US/addressbook.properties instead of mail/locales/en-US/chrome/messenger/addressbook/addressBook.properties) This is the correct file, same change though so carrying forward r + sr from bienvenu.
Both Updated patch & Thunderbird checked into trunk, note that the original patch was from bug 122282 and Philip K. Warren (IBM) <firstname.lastname@example.org>. /cvsroot/mozilla/mailnews/addrbook/resources/locale/en-US/addressBook.properties,v <-- addressBook.properties new revision: 1.35; previous revision: 1.34 done Checking in mail/locales/en-US/chrome/messenger/addressbook/addressBook.properties; /cvsroot/mozilla/mail/locales/en-US/chrome/messenger/addressbook/addressBook.properties,v <-- addressBook.properties new revision: 1.6; previous revision: 1.5
Comment on attachment 194587 [details] [diff] [review] Updated patch a=me for SM1.0b on SM only part of code, 2nd needed one - Tally Ho!
"Updated patch" (SeaMonkey only) checked into 1.8 branch for SeaMonkey 1.0b
(In reply to comment #11) > "Updated patch" (SeaMonkey only) checked into 1.8 branch for SeaMonkey 1.0b > Also checked into 1.8.0 branch.
Comment on attachment 197349 [details] [diff] [review] Real Thunderbird version Requesting approval for 1.8.1 branch, small patch that corrects the file format type display.
Thunderbird patch checked into 1.8.1 branch (SeaMonkey version already there).