Closed
Bug 875996
Opened 12 years ago
Closed 9 years ago
Address book setting for preferred received delivery format (HTML vs. Plaintext) not being read
Categories
(Thunderbird :: Message Compose Window, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: sfhowes, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: regression, regressionwindow-wanted, Whiteboard: [needs followup bug for comment 44? Problems when setting different preferences for same address in different ABs])
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20130524 Firefox/23.0 (Nightly/Aurora)
Build ID: 20130524004018
Steps to reproduce:
Composed HTML message to recipient marked as preferring HTML format in Address Book.
Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Thunderbird/23.0a2
Build ID 20130524004021
Actual results:
Upon sending, the window that appears when the preferred format isn't known appeared, asking to choose plain text, HTML only or both.
Expected results:
Message should be sent without the need to specify the format.
I'm also having the same issue in Thunderbird 17.0.8 & 24.0.1 in Vista x64.
Many contacts were set in address book to receive html, but somewhere in TB 17.x.x, it started showing pop up, "some recipients...not listed as being able to receive html" for every message sent to contacts that *had* HTML selected as preferred format in address book.
Checking abook.mab showed some of the contacts that TB showed the pop up for, had values in abook.mab of (8E=2), so it should have sent html messages w/o asking.
Even exporting addr bk to *.ldif (removes values for which message format to use on each contact),
closing TB,
deleting old *.mab files,
restart TB &
import .ldif files back,
close TB again,
then manually editing (8E) cells to values =2 for several recipients & save file, didn't stop the pop up, asking which format to send in (I assume it's only looking at the recipient(s) of CURRENT message.
Changing TB global setting - Options>Composition>General>Send Options, to "send plain text & HTML" stops the pop ups for me. But, I don't want to send everyone both formats.
Even when recipient are set to receive plain text (or no specification) AND there's no HTML formatting in messages, TB still asks, when sending messages.
Comment 2•11 years ago
|
||
can you more precisely cdetermine when (which day of daily builds) this went bad?
Flags: needinfo?(sfhowes)
Updated•11 years ago
|
Keywords: regression,
regressionwindow-wanted
(In reply to Wayne Mery (:wsmwk) from comment #2)
> can you more precisely determine when (which day of daily builds) this went
> bad?
Sorry, can't say exactly, but it was probably not much before I reported the bug. It's still here in today's Earlybird (TB 27), but I use this workaround: in Tools/Options/Composition/General/Send Options, select "Send the message in HTML anyway".
Flags: needinfo?(sfhowes)
Comment 4•11 years ago
|
||
(In reply to sfhowes from comment #3)
> (In reply to Wayne Mery (:wsmwk) from comment #2)
> > can you more precisely determine when (which day of daily builds) this went
> > bad?
>
> Sorry, can't say exactly, but it was probably not much before I reported the
> bug.
if the regression did not occur between 23.0a1 and 23.0a2 (I'm not sure if that's what you are implying), then we're talking about the 6 weeks gap between version 22 and 23, which isn't a useful regression range.
Comment 5•10 years ago
|
||
This might have been improved or fixed by the work done in bug 970118.
Sfhowes, can you provide more details about all plaintext/HTML settings involved in your scenario, and then state if they still fail or not?
per-account HTML composition setting
per-message Format > Delivery Format
prefers HTML for each recipient
Options > Composition > ... when one or more recipients are not known to prefer HTML, ask|send hmtl | send text only | send both (I paraphrase)
Depends on: 970118
Updated•10 years ago
|
Summary: Address book setting for preferred received format not being read → Address book setting for preferred received delivery format (HTML vs. Plaintext) not being read
Updated•9 years ago
|
Blocks: delivery-format-ux
Comment 6•9 years ago
|
||
Sfhowes, do you still see this problem in current version of TB?
If yes, please answer questions below.
(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #5)
> This might have been improved or fixed by the work done in bug 970118.
> Sfhowes, can you provide more details about all plaintext/HTML settings
> involved in your scenario, and then state if they still fail or not?
>
> per-account HTML composition setting
> per-message Format > Delivery Format
> prefers HTML for each recipient
> Options > Composition > ... when one or more recipients are not known to
> prefer HTML, ask|send hmtl | send text only | send both (I paraphrase)
Flags: needinfo?(sfhowes)
Whiteboard: [closeme 2015-11-30 incomplete]
(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #6)
> Sfhowes, do you still see this problem in current version of TB?
> If yes, please answer questions below.
>
> (In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment
> #5)
> > This might have been improved or fixed by the work done in bug 970118.
> > Sfhowes, can you provide more details about all plaintext/HTML settings
> > involved in your scenario, and then state if they still fail or not?
> >
> > per-account HTML composition setting
> > per-message Format > Delivery Format
> > prefers HTML for each recipient
> > Options > Composition > ... when one or more recipients are not known to
> > prefer HTML, ask|send hmtl | send text only | send both (I paraphrase)
Having done a few tests on Earlybird 44, I find the address book setting is obeyed, but if there is one instance of 'Unknown' format in All Address Books for a contact, the prompt is displayed. For example, a contact may have HTML as the preferred format in PAB, but Unknown in other address books, in which case the user is prompted to define the format. I guess if the algorithm gave priority to the PAB setting, this wouldn't occur. Or, if a setting is made in one address book, perhaps it should be inherited by all address books.
This happens with these settings: HTML for all messages for the account, and 'Ask me what to do...' for 'when one or more recipients...'. So, I will revert to 'Send in HTML anyway' to avoid the prompt.
Flags: needinfo?(sfhowes)
Comment 8•9 years ago
|
||
sfhowes, thanks for swift reply.
I understand that this bug as reported is now "worksforme".
Out of interest:
- Why did you set the preference to ASK ME?
- Do you have any prefers-plain recipients?
- Would it make things easier/clearer for you if there was a separate global preference for mapping "prefers-unknown" to "prefers-html (or plain, or both)"?
Comment 9•9 years ago
|
||
I'd agree with you that comment 44 is a bug in its own right, that having the same address in multiple ABs confuses evaluation of prefers-format, whereas it should be inherited for the address.
Feel free to file that as a new bug with clear STR.
However, I think that's part of the general wrong conceptual design of the entire AB, which invites such duplication and confusion. Every contact should be unique, and ABs it belongs to probably just a property of the contact. So that needs a complete ground-up-redesign of the AB, which has long been in the pipe, but never materialized, for lack of manpower.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Whiteboard: [closeme 2015-11-30 incomplete] → [needs followup bug for comment 44? Problems when setting different preferences for same address in different ABs]
Reporter | ||
Comment 10•9 years ago
|
||
(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #8)
> sfhowes, thanks for swift reply.
>
> I understand that this bug as reported is now "worksforme".
>
> Out of interest:
> - Why did you set the preference to ASK ME?
I believe that's the default, so most users operate in that condition.
> - Do you have any prefers-plain recipients?
No, I impose HTML on everyone!
> - Would it make things easier/clearer for you if there was a separate global
> preference for mapping "prefers-unknown" to "prefers-html (or plain, or
> both)"?
That's what setting the "Ask me..' option to 'Send in HTML anyway' does.
Comment 11•9 years ago
|
||
(In reply to sfhowes from comment #10)
> (In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment
> #8)
> > sfhowes, thanks for swift reply.
> >
> > I understand that this bug as reported is now "worksforme".
> >
> > Out of interest:
> > - Why did you set the preference to ASK ME?
>
> I believe that's the default, so most users operate in that condition.
No, the default is "Send both plain text and HTML", to prevent asking...
> > - Do you have any prefers-plain recipients?
>
> No, I impose HTML on everyone!
:)
> > - Would it make things easier/clearer for you if there was a separate global
> > preference for mapping "prefers-unknown" to "prefers-html (or plain, or
> > both)"?
>
> That's what setting the "Ask me..' option to 'Send in HTML anyway' does.
Well, yes and no...
That setting covers the following scopes:
allPlain, somePlain & someHTML, somePlain & someUnknown, someHTML & someUnknown, allUnknown
So for users who actually want to use that setting for their prefers-plain recipients (which imo is the original intention of the feature, including ASK), they will automatically change things for "prefers-unknown" recipients, too, which really spoils the purpose.
Even the whole description of "When one or more recipients are not listed..." suggests a focus on "not being able to receive HTML", which looks like a biased implicit assumption that "prefers-unknown==prefers-plain". Which for you and many others these days is a wrong assumption to make...
Also note that there's another caveat: Even when you have the setting for "Send HTML only", TB will still force-send plain text to your "prefers-unknown" recipients (and even to "prefers-HTML" recipients if mixed with other preferences) IF TB thinks HTML formatting of your particular message is not significant enough to be preserved (certain tags and many styles will be dumped). Currently there's no switch to prevent this "Auto-Downgrade before Auto-Detect" behaviour.
Alas, I'm at the forefront of trying to fix these issues (ongoing work in several bugs).
You need to log in
before you can comment on or make changes to this bug.
Description
•