OpenDocument File (ODF) format extensions in compose window should show reminder window to "not forget to add the attachment"

NEW
Assigned to

Status

enhancement
8 years ago
2 years ago

People

(Reporter: marc, Assigned: aceman)

Tracking

(Depends on 1 bug, Blocks 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.13) Gecko/20101230 Mandriva Linux/1.9.2.13-0.2mdv2010.2 (2010.2) Firefox/3.6.13
Build Identifier: 3.1.7

When typing content in the compose window, if .pdf or .doc is added, a warning "banner" on the bottom of the compose window pops up warning to not forget to add the attachments. Would it be possible to add the OpenDocument Format extensions to these by default as well. We should be promoting opensource formats and this will encourage people to use OpenDocument Format (ODF) if they see if supported in mainstream software such as Thunderbird. For such little effort in adding this by default in the installation, you will be showing support for these formats rather than showing support for only the .pdf and .doc format as well as showing support for the opensource community.

Reproducible: Always

Steps to Reproduce:
1.Just add any text into the compose window and add .pdf and .doc and a reminder window will pop up on the bottom. If you add: .odt or .odp or .ods or .odg or .odb or .odf from the OpenDocument Format extensions, there is no reminder at all for these. If this were added in the default installation it would show great support for the ODF formats.
2.
3.
Actual Results:  
No pop-up reminder window for any ODF extensions.

Expected Results:  
A pop-up reminder window should show just like for .pdf and .doc extensions.

Comment 1

8 years ago
Though the keyword list allows to be extended manually, having just ".doc" and ".pdf" in the default set is a bit too selective. Bug 547589 would certainly simplify adding rules like ".od[tpsgbf]" for OpenOffice-generated documents, and it's a common alternative to Microsoft's Office package. Thus confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → ludovic
Status: NEW → ASSIGNED
Attachment #512819 - Flags: review?(bwinton)

Comment 3

8 years ago
The reason why I mentioned bug 547589 is that it would combine an elegant way to group related file types, such as ".{{doc,xls,pp[ts]},x}" rather than having a flood of single file-extension entries in the keyword list. Either way, it may be worth adding the Microsoft counterparts .xls and .ppt (maybe .rtf and .pps) if you want to stick with separate entries.

Comment 4

8 years ago
(actually, ".{doc,xls,pp[ts]}{,x}" not ".{{doc,xls,pp[ts]},x}" would match
 .doc .docx .xls .xlsx .ppt .pptx .pps .ppsx, but you get the idea...)
Comment on attachment 512819 [details] [diff] [review]
Adding Libre Office extensions v1

This looks good to me.  And I believe the existing tests should cover this change well enough that we don't need to add more.

Spinning off a separate bug to add .ppt and .xls would be nice.
Attachment #512819 - Flags: review?(bwinton) → review+
Blocks: 635938
-mail.compose.attachment_reminder_keywords=.doc,.pdf,attachment,attach,attached,attaching,enclosed,CV,cover letter
+mail.compose.attachment_reminder_keywords=.doc,.pdf,.odf,.odt,.odp,.ods,.odg,.odb,attachment,attach,attached,attaching,enclosed,CV,cover letter

Hmm, I wonder if we should be changing the string name so that localisations will pick this up.
(In reply to comment #6)
> -mail.compose.attachment_reminder_keywords=.doc,.pdf,attachment,attach,attached,attaching,enclosed,CV,cover
> letter
> +mail.compose.attachment_reminder_keywords=.doc,.pdf,.odf,.odt,.odp,.ods,.odg,.odb,attachment,attach,attached,attaching,enclosed,CV,cover
> letter
> 
> Hmm, I wonder if we should be changing the string name so that localisations
> will pick this up.

If so I'll resubmit a patch with the content of bug 635938. 

Do you have a proposed new keyword ?

Comment 8

8 years ago
(In reply to comment #6)
> -mail.compose.attachment_reminder_keywords=.doc,.pdf,attachment,attach,attached,attaching,enclosed,CV,cover
> letter
> +mail.compose.attachment_reminder_keywords=.doc,.pdf,.odf,.odt,.odp,.ods,.odg,.odb,attachment,attach,attached,attaching,enclosed,CV,cover
> letter
> 
> Hmm, I wonder if we should be changing the string name so that localisations
> will pick this up.

What about defining file extensions independently from the localization and appending them to the localized mail.compose.attachment_reminder_keywords ? I think it would make sense, and the localizations would still be able to add their own extensions if needed.

By the way, maybe .docx,.xls,.xlsx,.xps should also be added?
Yeah, what Rimas said.

Comment 10

8 years ago
Keep in mind though that mail.compose.attachment_reminder_keywords is the name of the underlying preference, thus you don't want to change that property.

Re mail.compose.attachment_reminder_filenames (or whatever new name), it may make sense given that keywords and file extensions are different things. I still think that a wildcard/expression-based matching would be better for these kind of similar but different entries (otherwise you'll need yet another UI element for modifying the file-type entries, etc.).
>kind of similar but different entries (otherwise you'll need yet another UI
>element for modifying the file-type entries, etc.).

That's where I end up being. I think having two list would be clumsy for the user.
Bryan thoughts ?
(In reply to comment #10)
> Keep in mind though that mail.compose.attachment_reminder_keywords is the name
> of the underlying preference, thus you don't want to change that property.

This is actually a good point. L10n just doesn't cope with this sort of thing.

I'm starting to wonder if we're going to end up with some sort of moving pref and having to migrate it.

Although maybe what we could do is this:

mail.compose.attachment_reminder_keywords<n> is the latest version of the preference (where <n> is a number), as determined in the code.

mail.compose.attachment_reminder_keywords (no number) is where we store the user-preference of the values.

If the user-preference is set we use that, else we use the latest version of the preference.

This way l10n can have a preference bump each time we add to the list.

The downsides are:

- If a user modifies prefs.js via about:config they will likely set the wrong value. I think that we can just say that's not recommended for setting that pref.

- When we change the default value of the pref, users who have updated that pref manually won't get the update. This is the same situation that we're in now, and I'm not sure we can easily do much here.

Comment 14

8 years ago
Just to make it clear, I suggest that the default file extensions should NOT be localizable (well, except perhaps for some special cases, which could be handled 
by prefs.js).
These extensions *could* be stored in a hidden pref, but I don't think Tb should make the list available for editing in its UI. IMO, this option isn't very likely to be of interest to our user, and we're not SeaMonkey. :)

Comment 15

8 years ago
Why do you want to keep the file extensions hidden from the user? For the same reasons that one may want to adjust the keyword list, you may want to add those file types you frequently use personally (but maybe "nobody else"), and remove other file extensions you don't care about ("who's using MS Word?").

Comment 16

8 years ago
(In reply to comment #15)
> Why do you want to keep the file extensions hidden from the user? 

I said it above, IMO, this option isn't very likely to be of interest to our user, and we're not SeaMonkey. :)

> For the same
> reasons that one may want to adjust the keyword list, you may want to add those
> file types you frequently use personally (but maybe "nobody else"), and remove
> other file extensions you don't care about ("who's using MS Word?").

Well first of all, I don't think these extensions would get in anyones way. Whether or not you're using MS Word, you're probably not very likely to have a string ".doc" in your message, except when mentioning .doc files.

On the other hand, if you want to add your own extension, you could still do one of the follwing:
a) add it to the list of words (mail.compose.attachment_reminder_keywords) which is configurable. Would you care enough that this list doesn't support regexps?
b) if you're a geek enough to want to use regexps (assuming bug 547589), you would probably not be too scared to edit the hidden pref (e.g. mail.compose.attachment_reminder_regexp) and add your extensions to it using about:config.

Comment 17

8 years ago
Fair enough, I'll leave it up to Bryan whether going with two prefs is the right way. It would in theory provide context if a keyword is a "real" keyword or just a file extension (thus aiding bug 547589 or bug 635993), but the user may - as you say - just add an extension to the keyword list and thus screw up any logic based on different interpretation of the prefs.

> and we're not SeaMonkey. :)

...which doesn't offer that feature, by the way. :-D
I don't think you really want me to comment on the implementation of using two prefs so I'll just try to lay out the way I believe this should be working so you guys can figure the rest out.

The user has a list of possibly modified keywords they want to search for and we need to preserve any changes they make to that list.  At the same time we also want to be able to update that list periodically in releases.  My tech suggestion would be that we have some way to append new elements to the users list but that the user list stays the same; take that or leave it.

Separating out keywords and file extensions might be something nice we could do in the keyword UI.  This would likely have the benefit of helping people find keywords and easily add/remove file extensions.  But it would still need to have the same properties where people could remove any item from either list.  I'd be willing to work on this but I wouldn't personally push this as a priority right now since the current single list works pretty well for most peoples needs.  Adding a lot more extensions makes this list larger but not significantly at this point.

I'll comment on the regex bug later but I'm sure you've already guessed that I feel like this is not going to be a great thing to enter into the product.  The regex support will enable a small set of users to have very powerful searches while increasing complexity and possible confusion for almost all users.  We could work to have them coexist but really with some sub string matches most users will be fine with the existing string searching.  Regexes are programming languages and so they require a good understand of how they work, testing, and almost always come with bugs.
Shall we maintain Three list ?
 current list of keyword
 list of keywords that were removed
 list of keywords we want to add as part of an update
 An update flag.

Startup sequence -> is update flag to true ?
 Yes
  read the add list , is the keuword in the removed list ?
     yes read next keyword
     no is it in the current list
     yes read next keyword
     no add it to the list

I think This would work - thoughts ?

Comment 20

8 years ago
I think the things suggested here are getting increasingly complex for no real reason. The purpose of that list is to offer *sane defaults*. I think it's absolutely fine that as defaults are updated, already existing users settings remain the same. This list of keywords is far from being as volatile as say anti-virus definitions. I think it can perfectly live on wiithout our intervention, after the account has been created.

The suggestion I gave in comment #8 was to simply make a core set of file extensions independent from the localization used, because they're not as likely to vary between locales as the real keywords.

Comment 21

8 years ago
The most generic solution to this problem I can think of would be to collect all file extensions from mimeTypes.rdf, then get a list of registered file types and their extensions from the operating system, and use this as the second list without restricting it to some fixed set of file extensions to start with. Since this may cause too many false positives, maybe trigger only for a set of MIME-type classes (e.g., application/*, image/*, and text/*).

While this idea sounds like a nice solution, it may be likely overdoing it. Separating file extensions from "regular" keywords in a second preference, as long as there is no different treatment of such (comment #17). Going with Rimas' suggestion is probably a good trade-off among interests and effort.
(Reporter)

Comment 22

8 years ago
I was wondering if this was still being considered? It looks like it mushroomed to having more than the suggested ODF extensions. The initial suggestion was that Thunderbird recognize the ODF extensions just as it does with .doc and .pdf. Adding the ODF extensions would lend support to the OpenSource platform of which Thunderbird belongs rather than recognize only .doc and .pdf proprietary extensions.

BTW ... OASIS standard ODF 1.2 has just been approved [http://lists.oasis-open.org/archives/tc-announce/201109/msg00010.html].
Assignee: ludovic → nobody
Status: ASSIGNED → NEW

Comment 23

6 years ago
This depends on bug 545837 (make attachment reminder keywords language-sensitive) because if we do that bug we'll probably need a different approach here.
Depends on: 545837
(Assignee)

Updated

4 years ago
Depends on: 1146587
(Assignee)

Updated

4 years ago
Blocks: 1146587
No longer depends on: 1146587
(Assignee)

Comment 24

4 years ago
I should look at refreshing this. It even has partial patch.
Assignee: nobody → acelists
Version: unspecified → Trunk
Duplicate of this bug: 1320443

Comment 26

2 years ago
(In reply to :aceman from comment #24)
> I should look at refreshing this. It even has partial patch.
Perhaps you should before we collect more duplicates ;-)
You need to log in before you can comment on or make changes to this bug.