[Bug 106737]
Aceman, given the high popularity of this bug, can't we use the workaround as
an interim fix when
renaming foo to Foo:
sourcefolder=foo
targetfolder=Foo
if (lcase(sourcefolder) == lcase(targetfolder)) {
- first rename foo to foo.tmp_random
- then rename foo.tmp_random to Foo }
Renaming folders doesn't happen every day, so taking a split second longer
doesn't matter.
That way, it'll work for all types of folders/OSs/POP/Imap no matter what
(except for those where the server doesn't allow renaming).
Then, we can spend the next decades looking for the real fix. Or maybe this is
the real fix, because even some servers don't accept changing capitalization
only, so we'd elegantly trick those.
The only scenario where this might fail are extra long nested folder names at
the limit, where we might fail to create the tmp target folder if the tmp path
gets too long or such.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/106737
Title:
Renaming folder to same name but different case not allowed
To manage notifications about this bug go to:
https://bugs.launchpad.net/thunderbird/+bug/106737/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 106737]
*** Bug 1708164 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/106737 Title: Renaming folder to same name but different case not allowed To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/106737/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1774121]
Created attachment 9218969 For comparison: Win10: Choose Folder dialog with [Select Folder] button on 78.10.0 For comparison: TB's folder picker dialog for saving multiple messages on Win10/TB 78.10.0 is better (but also not ideal, e.g. no hint for saving): Dialog titled "Choose Folder" (that looks set by TB, as it's non- localized), button labelled "Ordner auswählen" (German for "Select/choose Folder", so that's probably Win10-dialog-inbuilt). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1774121 Title: Save button on "Save All Attachments" dialog says "Open" To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1774121/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1653351]
*** Bug 1585532 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1653351 Title: Have option to not automatically open next email To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1653351/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1653351]
*** Bug 1681092 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1653351 Title: Have option to not automatically open next email To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1653351/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 810769]
(In reply to Wayne Mery (:wsmwk) from comment #27) > The "lack of interest" by users is perhaps because most users don't know it's > possible to do this. The lack of progress in a decade on the blocking bugs > of course doesn't help. > > ISTM we only need to fix a couple bugs to make this good enough to send out > for wider testing. What do others think? Having this would surely be useful to make us look and feel better. I'm not sure how much priority it would be worth, maybe I'd prefer to fix even more basic scenarios (e.g. that after saving (downloading) an attachment to your disk, there's zero hint in the UI how to open the target location with your OS file manager, so unless you already know about Ctrl+J, you'll have to start navigating all the way to that attachment in Explorer whereas TB knows exactly where it is). > Perhaps a good starting point is Bug 749654? Bad message in Outbox blocks delivery of remaining messages until dialog is dismissed. Bug 749654 is an excellent starting point, that nasty thing really needs fixing although it may not be in everybody's workflows. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/810769 Title: Sending window distracting and interrupts flow To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/810769/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1085]
(In reply to Jorg K (GMT+1) from comment #43) > Created attachment 8693516 > Unbitrotted patch. > > I found this bug looking for "patchlove". I refreshed the patch. > > This is the result: > from: =?UTF-8?Q?J=c3=b6rg_Knobloch?= > subject: some subject > to: some...@somewhere.com > > Pretty ugly: > - The headers need to be RFC 2047 decoded. > - lowercase in the field names. That sounds doable? > So the question is, before I invest more work here: Does anyone want this? Definitely yes. 17 votes, 8 duplicates across many years. And it's just a freaking annoyance if any relevant text content which is right in front of me cannot be copied and reused for other purposes. Email addresses clearly qualify as relevant text content. Subject is already copyable. > The nice add-on "HeaderToolsLite" also gives access to the headers, you can > even edit them. Thanks for the pointer. Ability to copy relevant text content should be core functionality. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1085 Title: selecting text in full header mode fails To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1085/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1085]
Having a menu command for copying the entire header as a block is certainly a big step forward, but in the long run I'd actually expect to be able to select any amount of header text in-place, right there in the actual headers (like for subject now). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1085 Title: selecting text in full header mode fails To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1085/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1085]
(In reply to Jorg K (GMT+1) from comment #55) > In comment #47 Thomas said: > > in the long run I'd actually expect to be able to select any amount of > > header text in-place > While this is desirable, it's also hard to do right now. So I'll leave this > bug for now and fix bug 327621 instead. Only that this bug 167010 and bug 327621 are duplicates, so you'll still be working on the same thing... ;) Adding context menus for copying is here: Bug 7 - [SM] "Copy email address" doesn't copy name Bug 232021 - name should be included with email address when copying from header menu -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1085 Title: selecting text in full header mode fails To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1085/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1085]
(In reply to Samuel Åslund from comment #57) > While waiting for this to be fixed could we have a button "new email to all > recipients", possibly behind the "more" menu/button, since that probably is > one main use of the copy feature. Thanks Samuel, but, hmmm, probably not. Have you tried using "Reply All" (Ctrl+Shift+A) or "Edit as New Message" (Ctrl+E), then remove msg body and attachments)? > By the way, the workaround to open the source and copy / paste from there > does not work well when UTF8 characters are involved. > Pasting what is copied from the message source into the address field does > not convert the encoded character back, it shows the encoding. Yeah, source it's an animal of its own, there might well be shortcomings there. Please file bugs if they haven't been filed yet. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1085 Title: selecting text in full header mode fails To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1085/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1085]
*** Bug 1688134 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1085 Title: selecting text in full header mode fails To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1085/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1514161]
(In reply to Massimiliano Caniparoli from comment #12) > I just read from [TB 79 Beta release > notes](https://www.thunderbird.net/en-US/thunderbird/79.0beta/releasenotes/) > that this should be solved now, and I tried once. Could you please test it as > well? :) No, that's Bug 1644084 which was fixed, not this one. As you can see, this bug 1318405 is still `NEW`, i.e. not yet fixed. But in fact, this bug is also worksforme (maybe fixed by Bug 1644084) on TB 79.0b1 (32-bit), Win10. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1514161 Title: Address Book search loses filter when multiple entries found and one is deleted To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1514161/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 66566]
Does this still cover the original intention of this bug and several duplicates that users want an option (ideally on by default) where Ctrl+Enter in location bar opens the address in a new tab? It's confusing that sometimes we need to press Ctrl and sometimes Alt to open things in a new tab. Why can't we just make ALT the default canonizer shortcut key? Otherwise allow user to switch canonization off and have Ctrl+Enter = open in new tab behaviour instead. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/66566 Title: Inconsistent shortcuts for new tab To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/66566/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 66566]
(In reply to Marco Bonardo [::mak] (Away 9-26 Aug) from comment #103) > I made a small sheet to better understand what changes here, please check > and comment if something doesn't look correct. > https://docs.google.com/spreadsheets/d/ > 1VVEVjyIYRZIFteM71j5bJhENa2xXT82gaikr0WgpKLA/edit#gid=0 > > I didn't test the patch, I just assumed, on IRC Gijs said it's likely > different. > Anyway, I added a row with the behavior I'm suggesting, that is pretty much > the same as Chromium, apart ALT+Enter on the Mac. Unfortunately, I failed to access that table. Can you make it public? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/66566 Title: Inconsistent shortcuts for new tab To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/66566/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 235101]
*** Bug 224852 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/235101 Title: Can't select/copy/paste address block from Address Book in Thunderbird To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/235101/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 10883]
*** Bug 742244 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/10883 Title: Stuck in proportional font mode To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/10883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1085]
*** Bug 540729 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1085 Title: selecting text in full header mode fails To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1085/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
*** Bug 1059630 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
Aceman, Suyash, can you look into this? (See starting points at the
bottom of this comment)
STR are found in comment 45, please ignore comment 0 which has a wider
scope not applicable for what we want here.
This bug should be fixed *as a matter of urgency* and landed into TB
ESR31, because it renders the nickname feature practically useless
without insider knowledge and is now more exposed after the landing of
autocomplete twin bugs, bug 529584 and bug 558931.
Although some of the adverse user comments on those bugs are just
inconsiderate noise and nonsense (even suggesting we should not search
email addresses for recipient autocompletion!), for a certain subset of
users there's a trend of complaining that it's now harder to find their
favourite addresses with very short searchwords of just one or two
characters, for which case they'll see more results not returned before,
due to new contains algorithm (*foo*). It all depends on search patterns
and AB data structure, but I suspect such users are typically
older/longterm private users with small address books. In such user's
perception (as evidenced on comments), the old beginsWith algorithm,
combined with popularityIndex plain counter, was effectively acting as a
shortcut system to their favourite recipients, where typing "Ang"
*appeared* to reliably return their favorite contact, "Angus Miller". Of
course that has never been true and would fail also in TB 24 even for
simple scenarios where user might also have frequent conversation with
"Angus Johnson", "Angelina", and "Angelo". But in the combination of
narrow beginsWith algorithm and popularity Index, that problem was often
hidden for small ABs in private use.
So what such users really want is a stable 1:1 shortcut relationship
between their short searchwords ("Ang") and their favourite contact
associated with that ("Angus Miller"). That's where we fail miserably
because of this bug: Traditional nicknames like "Tom" will largely fail
because the contact where Nickname=="Tom" will not be reliably toplisted
in autocomplete results, so you end up with "Tony Tomson" toplisted
instead if he has a higher popularityIndex.
The other bad problem now more exposed and hence urgently in need of
fixing in this context (but much harder than this here), is Bug 382415
(replace popularityIndex with frecency algorithm for autocomplete based
on user inputs and picked results), for which a temporary simpler
improvement might be something along Bug 1058583 (aging algorithm for
popularityIndex).
Aceman, Suyash, this bug here should be relatively easy to fix; starting
points in code and outline of potential fix found in comment 50 and
comment 51.
(In reply to Thomas D. from comment #54)
> Aceman, I think this shouldn't be too hard and will be very similar and in
> same code area as your sophisticated patch in Bug 984875, attachment 8428850
> [©] [details] [diff] [review]. My comment 50 and comment 51 also provide a
> starting point how this could be done. Perhaps the combination of your
> insight and my starting points might enable you to come up with a draft
> patch here?
(In reply to Thomas D. from comment #55)
> Oh, and somewhat contrary to comment 0, my understanding of this bug is that
> most importantly, we want to toplist autocomplete results where
> nickname==searchstring (full string match). Haven't thought about partial
> nickname matches much, but strongly suspect we shouldn't undermine
> popularity more than necessary, so just toplisting full string matches would
> suffice for this bug (ignore other sorting suggestions found in comment 0).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/956618
Title:
Nickname not over-riding names in email address
To manage notifications about this bug go to:
https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 357864]
UX-error-prevention / Pref 1) General interest and usefulness of this feature seem to have declinied: Last duplicate of this bug filed 2006, 8 years ago. Only 4 supportive comments since 2005. As we speak, many common email-providers do no longer allow defining random "From" values, to prevent spam/spoof. 2) Otoh, adding this feature by default has a big error potential, as editing sender can prevent users from successfully sending their message (which they will only notice after sending). Which makes this a case of UX-error-prevention. 3) I conclude from 1) and 2) that this feature should be preffed-off by default, and I suspect hidden pref might suffice for the type of advanced users who have their own domain to tweak senders at random. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/357864 Title: Editing the "From" field for the current email only (as text, not dropdown) To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/357864/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 357864]
(In reply to Josiah Bruner [:JosiahOne] (needinfo > CC) from comment #109) > Created attachment 8544150 > Example sketch. I'm not sure if the sketch UI will work out well as presented; imo it might easily create confusion and wrong assumptions about this feature. >From selector in compose UI of current release has simultaneous double >function: Select a predefined sender identity as a set consisting of a) From-field of sent msg: John Doe b) SMTP-Server & login for sending: smtp.gmail.com, port: 465, SSL/TLS, normal password, username: john(at)gmail.com If I understand this bug correctly, for a given(!) identity selected by user from the dropdown, we want to allow editing a) (From-field) only, but we still rely on getting b) SMTP-Server from the original identity. "Enter a custom address...", more so at the bottom(!) of the dropdown list, wrongly suggests that user could create a new address/identity at the same level as the other identities in the list, which is not the case. Instead, the UI should reflect that we only allow window-dressing of the From-field text value within a predefined identity (which btw will not work for many commonly used mail servers, so we also need to think in terms of ux-error-prevention!). I agree with Josiah's comment 102 (supported by Ben's comment 107): (In reply to Josiah Bruner [:JosiahOne] (needinfo > CC) from comment #102) > Comment on attachment 8507858 > 87987.png > > I think what we should do is ... show the drop down if they > click anywhere other than an edit button. The edit button could go where the > dropdown icon is now for example. Tentative UI/UX proposal: 1) non-hover, non-focus: [John v] - hide edit icon/button - single-left-click from-selector anywhere opens dropdown (big click target for default workflow of picking predefined identity from list, as proposed by Josiah/Ben) - double-click anywhere -> edit sender (double click does nothing useful otherwise, so it's free). 2) hover, focus: [John [/] v] - only when hovered or focused, show a small "Edit" icon [/] (e.g. pen) - imo per ux-natural-mapping, the correct position for this icon, as hinted by Josiah, is *inside* the dropdown (correctly implying you can edit the inner value based on prior choice in dropdown). - clicking the "Edit" icon allows editing of From field value, either dialogue (allowing explanation of dangers involved for unsuspecting users), or inline (how do we handle ux-error-prevention then?) 3) popup (without editing): [John [/] v] |John private | |John tertiary | +--+ - if user hasn't edited anything, clicking anywhere on from-selector outside "Edit" icon will open the normal and unmodified popup - imo we should *not* advertise this feature more by offering a dedicated action row inside the dropdown, ux-error-prevention for default users: many smtp servers will reject altered from-fields, especially when you change the email address - consider if the entire feature should be preffed-off by default, again ux-error-prevention 4) popup (with/after editing): [Johnny Edited [/] v] |*John | |John private | |John tertiary | +--+ - after manual editing, we need to offer an easy way of reverting to the original identity whose from-sender was edited: offer as first entry in the dropdown, with some indication (icon, bold, etc.) that this the currently used identity (only with edited from). 5) Context menu ++ |Edit this sender| |Copy| |Paste | ++ - optionally for this bug, but recommended, implement a simple context menu on the from-selector - Edit this sender -> edit sender (dialog/inline) - Copy: Copy the current value of sender, either original "John " or edited "Johnny Edited " - Paste: Paste clipboard text to become the new edited value of sender - Copy and Paste might need better strings to indicate what they do -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/357864 Title: Editing the "From" field for the current email only (as text, not dropdown) To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/357864/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 357864]
(In reply to n...@parkwaycc.co.uk from comment #133) > Created attachment 8572084 > Possible patch > > I hid the option in the Options menu where it might be less discoverable. Screenshot would be nice. > (In reply to Thomas D. from comment #132) > > - allow editing only after double-click on sender (plus first-time warning) > Probably not possible because the popup code gets in the way. > Also, what do you do from the keyboard? Got me. Double-click isn't keyboard accessible... :| -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/357864 Title: Editing the "From" field for the current email only (as text, not dropdown) To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/357864/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 357864]
(In reply to Ben Bucksch (:BenB) from comment #129) > (In reply to Josiah Bruner [:JosiahOne] (needinfo > CC) from comment #125) > > UI-Review: > > - "Customize From Address" is confusing. “Enter a custom address” perhaps? > "Customize From Address"|"Edit Sender" vs. "Enter a custom address" are two different design concepts. "Customize/edit..." assumes we're using existing identities (including their predefined smtp), and only allow changing the sender string. This design does not work well as a dropdown entry at the end of the list, but requires UI elements/procedures to start from the currently selected sender identity. "Enter a custom address" (as last entry from dropdown list) suggests we allow adding a *new* sender, which would most certainly require to allow picking SMTP, too (because otherwise from this design it would not be clear which SMTP will be used). Both concepts have their advantages and disadvantages, which we are in the process of discussing. > > > - What if users try to use it as a separate address and they don’t actually > > have the account added to TB. Any replies to it will never show up. > > * (I'm thinking of naive users who think they can enter whatever address > > they "own" here without bothering to add the actual account, and expect us > > to add it automatically or something. > > - Is this going to encourage spam sending? I can send a message as > > “barackob...@usa.gov” now. I understand the capability was there already, > > but now it’s going to be even easier to do. This feature could be seriously > > abused. > > You question this whole feature, its very nature. Fortunately, it's allowed to question the nature of a feature. This feature is very questionable, and comes with a high potential for user errors. > Spammers don't need Thunderbird, they have specialized tools. And spammers > already do this in billions. +1 > This feature might actually help educating > users how easy it is to forge email addresses, and to be more careful when > they see From: i...@paypal.com "Please update your address". Well, maybe. I believe its more likely we'll end up with users who accidentally break their communications (failing deliveries; not getting replies). > > - What server are we actually sending this message through? We should > > probably have some capability to choose which one. > > * If you really want to pref this feature away, I think the best way would > be a checkbox in "Account Settings..." | "Manage Identities...". > * If we insist that only one account can have this checkbox checked, it > would solve the "which SMTP server" question > * But it would make this feature very obscure and hard to find. +1. Limiting this feature to one account is not required and very poor design. For ux-error-prevention, I suggest that this feature should not be actively promoted in the primary UI. There might be several ways of achieving this, e.g. - pref-out for each identity - allow editing only after double-click on sender (plus first-time warning) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/357864 Title: Editing the "From" field for the current email only (as text, not dropdown) To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/357864/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 357864]
I still think that the current UI for this is wrong because it's disjunct/dislocated. If we allow to edit the currently selected sender, then the control to start that should be near that sender. Clicking at the low end of a dropdown to edit the current entry at the top is bad UX imo. Also, there's a scalability problem for users having many pre-defined accounts and identities. That command to edit the sender might end up as the 50th entry, requiring scrolling to see it and other such nuisance. Just never put action commands to the end of a potentially unlimited list of things. We've tried that before (TB Tags list), and it never works. That's basic UX principles, really. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/357864 Title: Editing the "From" field for the current email only (as text, not dropdown) To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/357864/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 357864]
UX input: I definitely want this feature pref'ed off. This is very advanced stuff, and quite hazardous when used wrongly (users might not notice, or too late, that their important emails haven't been sent by server because they mis-tweaked their sender address). Just warning once imo is not enough. I'm not happy with the warning text in comment 142. E.g. the danger of failing to deliver is not even mentioned. Warning users against committing crimes is inappropriate for TB imo. It's probably not easy to get the warning right. The warning is less relevant when the feature is pref-ed off, so only people who really want this and know what they are doing will switch it on. On the plus side, the gmail scenario is quite powerful, being able to create john+filterw...@gmail.com on the fly might be useful. Otoh, I'm not sure how many usecases/scenarios there would be where I'd want to use such an email address only exactly once. For repetitive use (even 2 times), it's probably more useful to set up another identity on an existing account. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/357864 Title: Editing the "From" field for the current email only (as text, not dropdown) To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/357864/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 357864]
(In reply to Ben Bucksch (:BenB) from comment #147) > When I select an identity, click "Customize From Address", and edit it, I > then can still select other identities, and they will apply. That's good. > But when I select the same identity that I originally selected, I do not > return to the original From address, but my edited one stays. That's odd. > I'd argue that all dropdown entries should behave the same and reset the > edit field's value. However, that's a minor thing and also debatable. I > wouldn't hold the commit for that. Not being able to reset an edited sender to its original state does not look like a minor issue to me. How does this affect recycled compose windows? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/357864 Title: Editing the "From" field for the current email only (as text, not dropdown) To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/357864/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
(In reply to Deven Corzine from comment #43) > This worked in Thunderbird 2, which means it's a regression bug, not an Fwiw, notwithstanding the annoyingness of this bug, it is NOT a regression. I just tested this on TB version 2.0.0.24 (20100228), and nicks do NOT get absolute precedence in composition's recipient autocomplete (but it's easy to get fooled into thinking they do). I tested with this scenario (basically): Card1: firstname: n1n email: a...@asdf.com nick: n2n Card2: firstname: foo email: a...@asdf.com nick: n1n STR 1 compose new msg 2 in TO recipient field, type "n1n" Actual Result: - card 1 is at top of autocomplete list - ... Expected Result: - card 2 having fullstring match of nick should be at top of autocomplete list -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
This looks like one of the main places where we call addToResult(...) function (see comment 49). If that's correct, one way of fixing this bug might be this: Around here... http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/nsAbAutoCompleteSearch.js#146 146 let email = card.primaryEmail; 147 if (email) 148 this._addToResult(commentColumn, directory, card, email, true, result); ...perhaps we could get the nick field as we now get the email field, and then add matches of the search fullstring (is that available here?) against nick to a separate result array, say resultTop. Then merge resultTop Array with result array. We also need to sort multiple nick matches on something (because unfortunately it's possible to have multiple cards with same nick). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
For non-LDAP cases, I understand that it's this addToResult(...) function which finally sorts the autocomplete results list: http://mxr.mozilla.org/comm- central/source/mailnews/addrbook/src/nsAbAutoCompleteSearch.js#276 Seems to first sort on popularity here (after having removed duplicates)... http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/nsAbAutoCompleteSearch.js#309 ...and then on full addresses here (probably secondary sort): http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/nsAbAutoCompleteSearch.js#318 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
Given that all other nicks out there follow the inherent UX-concept of an ALIAS name or shortcut (where the nick is synomymous with its parent), and given that the FF equivalent of nicks aka "keywords" follow this inherent design principle correctly (nicks getting absolute priority in awesome location bar, even before frecency), this is also an issue of at least external ux-concistency. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
(In reply to Deven Corzine from comment #43) > How does such an obvious bug get filed and debated for year (2013), after > year (2012), after year (2011), after year (2010), after year (2009), after > year (2008), after year (2007), after year (2006)... but never actually > fixed? Deven, thanks for your feedback. I appreciate the frustration, as I've often felt it myself (being an active volunteer TB QA/UX contributor since 2007). However, we need to face the fact that TB has a track record of unresolved bugs for a variety of reasons. Where this bug is just one out of many, and the choice of "important" bugs to start from is pretty vast. TB is now maintained almost exclusively by volunteers, so getting this bug fixed requires a volunteer who is a) able, b) willing, and c) has the time to actually fix this, and d) an agreement about the exact goal of this bug, the desired UX how it should be fixed. a) and c) are the hard parts, whereas I'd consider d) a non-issue in this case (although looking at the entirety of comment 0, to which comment 12 responds, I suspect misunderstandings about d) also contributed to the long latency of this bug). > This worked in Thunderbird 2, which means it's a regression bug, not an > enhancement. Deven (and others before), thanks for pointing that out. Understanding the nature of a bug and documenting that as precisely as possible in the bug report is crucial. Indeed, this looks like a bug because it violates the very purpose of the nickname design, which is a 1 on 1 relationship between the (ideally unique) nick and the card, to allow user to retrieve and distinguish that card efficiently and consistently from all other cards. (As a caveat, note that TB is not enforcing uniqueness of nicks!). As has often been said in this bug, users correctly expect from the intrinsic purpose of nickname design, that nicks should have absolute priority in searches, which includes priority over frecency. Frecency is a way of automatically establishing dynamic nicks, but certainly nicks that have been purposefully and explicitly defined by user must take precedence over that (why should I add "wil" as a nick to my uncle's card if I don't want "wil" to find that very card?). Users who want the frecency algorithm to take highest precedence probably wouldn't (and shouldn't) define explicit nicks. Due to violation of these imo correct, established, and widely-evidenced user expectations, this is a bug in terms of UX error prevention where users can easily inadvertently send the msg to the wrong recipient(s), which is a major violation of their privacy. As such, this bug also undermines UX trust in TB as an application, as repeatedly stated here in line of comment 0 and comment 43: > You may not think this is important, but anything that causes mail to get > sent to > the wrong user inadvertantly is just about he worst possible problem a mailer > can have. > There has been ample evidence that this seemingly-minor issue > is a major source of frustration to many users, even to the point of > abandoning Thunderbird entirely. It may be a little thing, but that doesn't > mean it doesn't matter. > > Instead of debating the best algorithm for years, why not at least add a > special-case check for an exact match of a unique nickname, before going > into the current algorithm? That would satisfy the critical use case, > making most of the frustrated users happy. A special-case should be trivial > to add, for anyone who knows the code, so why hasn't that much been done > after nearly 8 years of this ticket being marked as NEW? See my remarks further up in this comment. Getting bugs fixed in TB is often less trivial than it looks, for a variety of reasons... FTR: I agree that the obvious solution to this bug (as required by the intrinsic principles of "nicks" design concept) is to list fullstring matches on nicks at the very top of the recipient autocomplete dropdown, so that they take highest precedence (even before frecency if we implement that). Btw FF works the same way for keywords: Keywords (not tags, nor frecency) take absolute highest priority over any other matches. Think of keywords and nicks as an ALIAS for the real thing. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
:aceman just fixed bug 529584 which is also about the result set in recipient autocomplete, so the patch there (attachment 803332) might be good starting point to identify the right spot in the code. And to everyone following this bug, if you have an interest in getting this fixed, even if you're not a code, it would have been a good idea to ensure that it isn't "assigned" to somebody who stopped working on this in 2008, because that will tell any other potential coder that there's nothing to do here because it's already taken by someone... :| -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
(In reply to Thomas D. from comment #45) > (In reply to Deven Corzine from comment #43) > > This worked in Thunderbird 2, which means it's a regression bug, not an > > Fwiw, notwithstanding the annoyingness of this bug, it is NOT a regression. > I just tested this on TB version 2.0.0.24 (20100228), and nicks do NOT get > absolute precedence in composition's recipient autocomplete (but it's easy > to get fooled into thinking they do). > > I tested with this scenario (basically): > > Card1: > firstname: n1n > email: a...@asdf.com > nick: n2n > > Card2: > firstname: foo > email: a...@asdf.com > nick: n1n Fwiw, I actually had these cards in different AB's (card 1 in Personal AB, card 2 in Collected Addresses). It shouldn't matter anyway. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
(In reply to Thomas D. from comment #50)
> This looks like one of the main places where we call addToResult(...)
> function (see comment 49).
> If that's correct, one way of fixing this bug might be this:
>
> Around here...
>
> http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/
> nsAbAutoCompleteSearch.js#146
> 146 let email = card.primaryEmail;
> 147 if (email)
> 148 this._addToResult(commentColumn, directory, card, email,
> true, result);
>
> ...perhaps we could get the nick field as we now get the email field, and
> then add matches of the search fullstring (is that available here?)
fullString (user's search words) are not explicitly available here (only
inside the searchQuery argument which is passed to _searchCards
function); but I suppose we could easily make it explicitly available by
just passing it as a separate argument into _searchCards function:
http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/nsAbAutoCompleteSearch.js#131
> _searchCards: function _searchCards(searchQuery, directory, result) {
-> _searchCards: function _searchCards(searchQuery, fullSearchString,
directory, result) {
So then when we call that function, we can just pass fullstring, too:
http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/nsAbAutoCompleteSearch.js#433
> this._searchCards(searchQuery, dir, result);
> this._searchWithinEmails(emailSearchQuery, fullString, dir, result);
-> this._searchCards(searchQuery, fullString, dir, result);
> against
> nick to a separate result array, say resultTop.
> Then merge resultTop Array with result array.
>
> We also need to sort multiple nick matches on something (because
> unfortunately it's possible to have multiple cards with same nick).
Perhaps we can get away with the current sorting algorithm of
_addToResult.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/956618
Title:
Nickname not over-riding names in email address
To manage notifications about this bug go to:
https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
(In reply to Thomas D. from comment #44) > users correctly expect from the intrinsic purpose of nickname design, > that nicks should have absolute priority in searches, which includes > priority over frecency. Frecency is a way of automatically establishing > *dynamic* nicks, but certainly *static* nicks that have been purposefully and > explicitly defined by user must take precedence over that. Adding "frecency", the big brother of this bug (but not required to fix this), is Bug 382415 - Popularity index of autocomplete doesn't honor timeline (use frecency for email contacts) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 490935]
(In reply to Lee_Dailey from comment #85) > this extension from paolo kaosmos does the job. it replaces the old > headertools extension mentioned in comment 37 and is actively supported. > - Headers ToolsLight: edit Subject, Sender, Full source etc > [Forum] http://forums.mozillazine.org/viewtopic.php?f=28&t=2300561 > it seems like a good workaround until tbird finally includes the ability. The addon can be downloaded from here (reported to work with TB24, and actively maintained): https://addons.mozilla.org/de/thunderbird/addon/header-tools-lite/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/490935 Title: it is not possible to modify email subject To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/490935/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 490935]
*** Bug 947267 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/490935 Title: it is not possible to modify email subject To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/490935/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 490935]
(In reply to Ben Bucksch (:BenB) from comment #88) +1, I'd like to register my support for Ben's support of this bug :) 65 votes and 15 duplicates with consistent inflow over a large time span are a good indication that "edit subject" feature has the potential of adding significant value for many affected users. Somebody care to search https://getsatisfaction.com/mozilla_messaging/ for user requests about this? > Why this is important: > > 1. You personally may not, but many users have fax->email services. If you are suggesting that a larger or in any way significant percentage of TB users use FAX-to-Email services, then imho that's a fiction from the same ideosyncratic historic world where plaintext messages are still so much the order of the day that we could just ignore the substantial dataloss of formatting/styles inflicted on users of HTML messages by your delivery-format "Auto-Detect" algorithm. Having said that, I don't think small numbers of users for a given feature is per se an argument against that feature; if we removed all features each only used by small percentage of users, we would end up removing large parts of TB feature set. On the contrary, I'd claim that qualitative aspects like the degree of disturbance by lost ux-efficiency should also matter. Which might apply to this bug: It's hard to tell how many users would actually bother to edit subjects, but for those affected by such problems, it's a significant interruption to their workflows. > For them, this feature is absolutely necessary. +1 > 2. If people set bad subjects for important emails (e.g. by just hitting > reply on an unrelated subject), I can either get angry at them (because I > will not find it anymore in one week), or ask them to fix it in the future, > or I can fix it myself in my mail store. The latter, however, I can only do > with this feature. +1 > 3. Many other people have wrong clocks on their computers, and Thunderbird > sorts folders by the message send time that the sender put in. I recently > received a mail which was exactly one month off. Completely confused me in > the folder view. I can't fix it, without this feature. (Arguably, > Thunderbird should sort better.) This bug is only about editing subject; editing any other header fields (like date) is not in the scope of this bug, and should not. It'll be more than hard enough to just land "edit subject" in a generally acceptable and functional manner (think IMAP), so expanding the scope of this bug would be the perfect recipe for never landing anything. > This is similar to "delete attachment" feature. That's also a feature that > we didn't have for a long time, and some said we didn't want it, they said > it's freaky and wrong. Finally, we added it - +1, there seems to be some analogy of technicalities and historical development. > and it's indispensable, as it turned out. OT: I have some doubts on that, given that the "delete/detach attachment" feature still has bugs (like wrong icon for detached files) without much activity from users iirc. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/490935 Title: it is not possible to modify email subject To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/490935/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
(In reply to Thomas D. from comment #38) > So resolving multiple comma-separated nicks is probably beyond the scope of > this > bug. I'd recommend filing a separate bug for resolving a comma-separated list > of > nicknames. OT: also about resolving multiple comma-separated nicks on one line: https://getsatisfaction.com/mozilla_messaging/topics/five_reasons_i_downgraded_to_v2 https://getsatisfaction.com/mozilla_messaging/topics/address_entry_has_gotten_worse_with_new_updates and probably more -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
This bug (and related bugs on nicknames) are supported by plenty of complaints at getsatisfaction: 265 topics found for nickname https://getsatisfaction.com/mozilla_messaging/searches?query=nickname&x=1&y=3&style=topics I stopped tagging gs reports after the first 2 or 3 result pages. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
(In reply to Brian Hauer from comment #21) > Expanding on the example above, assume you have nicknames "wil", "jan", and > "bob". You should be able to type "wil,jan,bob" to quickly address a mail > to all three. When focus leaves the field, the parser should expand each > based on a nickname match, resulting in three entries in the addressing user > interface. > [snip] > I consider nicknames to be a special case of address resolution. As the > proponents above have said, at the least nicknames should be treated as the > #1 priority in finding a matching address. But I would recommend going > further: namely, nickname resolution should occur -after- the > comma-delimited parsing of the user's input occurs. +1 to all of comment 21 and the underlying understanding of nicks as 1 on 1 aliases. However, focus in this bug is on giving resolved (single) nicks precedence in autocomplete results. So resolving multiple comma- separated nicks is probably beyond the scope of this bug. More reminiscent of (but perhaps not the same as) bug 295428. I'd recommend filing a separate bug for resolving a comma-separated list of nicknames. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
(In reply to Thomas D. from comment #38) > So resolving multiple comma-separated > nicks is probably beyond the scope of this bug. More reminiscent of (but > perhaps not the same as) bug 295428. I'd recommend filing a separate bug for > resolving a comma-separated list of nicknames. OT: Resolving other comma-separated things on recipients line, see also Bug 528503, bug 392932. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
See also: Bug 295428 - Names and nicknames should still work in address book without autocomplete Bug 118624 - AB quick search and contacts side bar does not search/match Nickname field, but should (ux-inconsistent with autocomplete) Bug 400713 - Allow showing any fields from address book as columns in compose message contacts pane (sidebar) [column picker, customize, sorting by organization, nickname etc.] Bug 247335 - Add separate "First Name", "Last Name" and "Display Name" fields to address book column picker for optional display in AB list pane -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1085]
I guess we might want to keep Thunderbird bug 327621 which requests the same so that it can be more easily found and remembered for the *Thunderbird* Product. Technically, it's a dupe of this bug 167010. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1085 Title: selecting text in full header mode fails To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1085/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1347305]
*** Bug 1051638 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1347305 Title: Address fields are grey when composing messages To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1347305/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1347305]
(In reply to Josiah Bruner [:JosiahOne] (needinfo > CC) from comment #2) > This was an intentional change made across platforms that makes text fields > appear as single lines when text needs to be entered instead of the bulkier > text fields. Imho how bulky text fields appear depends much on their borders and the overall design. Flat and borderless white against a normally lightgrey platform background isn't so bulky. Perhaps the pre-TB31 recipient area looked a bit nervous because there were so many borders all around. But I don't recall noticing any visual problems until the big redesign... It's also interesting to see the historical development of recipient area, perhaps someone could add screenshots of TB2, TB3.1, etc... TB2 is actually pretty close to the all-white background solution currently favored by Josiah. (Which is nice, but the problem starts when the formatting toolbar is added to that...) > However, it seems the general consensus is that the gray (which > originally wasn't so dark, but was changed to follow the Distro's styling) > gives the appearance of disabled fields on many linux distributions > (especially Ubuntu). Thunderbird as a desktop email application might be a more traditional/conservative thing in itself, where users (especially corporate) might care more about UX/functionality than innovative cutting edge design... But there's a more general question here how much we want to be consistent with OS platform design, vs. introducing an application-specific design... The answer is probably along the lines of what Blake said in comment 23, we need to strike a balance between being OS-conform and being ourselves as Thunderbird. Tricky... > I think we could probably clean up the linux styling. I haven't heard of any > Windows or OS X usability reports. Well, aceman and I have raised our concerns for Windows, and duplicate bug 1051638 (currently 5 votes) and bug 1061063 are both reported against Windows. Several comments on bug 1051638 are quite vocal against the current design. Even long-standing and loyal supporter like Anye Yelf who really isn't known for idiosyncratic or exaggerated criticism. Several users actually consider this a design bug and are quite surprised to hear it was intentional... Apart from the general issue, something which really disturbs me is that we're not even consistent *within* the new design. As discussed on the Toronto summit, we really shouldn't irritate users even more by having two competitive designs for the same type of control, namely Sender- dropdown vs. Recipient-type-dropdown. These are functionally exactly the same, so they should look and behave the same. I'm seeing this quite strongly on WinXP, where the dark-grey background of recipient type dropdown offsets a lot against recipient area background and I'm always wondering what's wrong with the recipient type that it still stands out from the all-flat header although it's not focused or disabled. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1347305 Title: Address fields are grey when composing messages To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1347305/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1347305]
*** Bug 1061063 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1347305 Title: Address fields are grey when composing messages To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1347305/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
*** Bug 1132681 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
Magnus, can you please set the appropriate flags to get this into a TB release version as soon as possible, even for TB31 if possible? I'm seeing more and more bug reports where users complain that nickname searches no longer work (they never have, but they appeared to... but now, depending on scenario / search words and data sets, users might see more irrelevant results, also because of irrelevant matches from collected addresses, resulting from our former mis-design (now fixed) to use collected addresses for remote-content permissions). We should really land all autocomplete fixes fast, to avoid getting more unqualified complaints for things we have already fixed. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
(In reply to Magnus Melin from comment #98) > I don't think this is ESR material as it's a new behavior not fixing a > regression. In view of 33 votes here and the quantity of bugs reported against autocomplete result sorting algorithm, I find that evaluation nitpicking. While in a strictly technical sense, this might not be a regression, it's actually worse: 1) Once upon a time we delivered a feature which apparently has never worked as intended and required by inherent design. That's a significant failure which shouldn't have to wait any longer when it's finally fixed 9 years after being reported. 2) We have only recently exposed this problem significantly more by expanding the scope of recipient search for certain scenarios. So, as seen from numerous reports, users are now more affected by this design problem, because of the changes made in recent version. Technicalities aside, that looks like a de-facto regression to me (as confirmed by users saying "it used to work until recently but now it fails"). I don't see any risks coming from this straightforward patch, except that we're undermmining popularityIndex a bit more again, but this works on exactly the same terms and conditions as Bug 970456 so there's nothing new here. So I still think this 5-line-patch should land on ESR. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
Magnus, thanks for approving this for beta and aurora. (In reply to Magnus Melin from comment #103) > As seen in the past every minor change might get someones use-case slightly > wrong. > We have usually let patches bake through aurora+beta before esr, but with 38 > coming up soonish I think what gets into 31esr should also be stricter. > > Based on other reports, there may be something fishy happening regarding > popularityindex, but I haven't had time to investigate that yet. Well, apart from the fact that popularityIndex is broken by design (because it just counts up forever so doesn't consider recency), the "fishy" thing which happened to popularityIndex is that your patch with new scoring algorithm in Bug 970456 effectively disables it for an unpredictably large number of usecases where search string happens to match the visible results strings in a wordwise manner, more so for matching the beginning of the visible result string, which is typically the display name. So no matter now popular certain results are, they can never get to the top. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
(In reply to Magnus Melin from comment #82) > This should be pretty straight forward to fix, now that bug 970456 is fixed. > You'd just adjust the scoring there to be higher if it's a match in nickname. Suyash, could you try this? It's pretty important to offer a 100% predictable way of using autocomplete shortcuts... Magnus has volunteered to mentor this ;) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
Comment on attachment 8557496
Patch v2
Review of attachment 8557496:
-
Thanks a lot Suyash for your quick response to my request to pick this
up - I am really getting tired of referencing and explaining this bug
(and workaround) in other bugs where users have been facing problems due
to this major flaw which practically disables the entire nickname
functionality for a range of scenarios.
I'll set feedback+ because we're on the right track here; but the devil
- as always - in the detail (i.e. this patch as-is won't work yet as
expected)...
::: mailnews/addrbook/src/nsAbAutoCompleteSearch.js
@@ +141,5 @@
> +// is the nick name for the card or at least in the beginning of it.
> +let nick = aCard.getProperty("NickName", "").toLocaleLowerCase();
> +aSearchString = aSearchString.toLocaleLowerCase();
> +if (nick.indexOf(aSearchString) == 0)
> + return BEST + 1;
(In reply to Magnus Melin from comment #86)
> You don't need the nick == aSearchString
> nick should act as a "super-best" match. so the score should be 1 better
> than if it matched in display name - as is they would be equal (=> we need
> BEST + 1)
True, but still not sufficient for ensuring absolute top ranking for *full*
nickname matches over *partial* nickname matches, e.g.:
Card1: Nickname="foo" (nick==searchphrase; nickIndex==0)
Card2: Nickname="foobar" (nick!=searchphrase; nickIndex==0)
Searchphrase: "foo"
Autocomplete result (wrong):
Card2 (partial nick match)
Card1 (full nick match)
To make the nickname design work reliably, full nickname match must
obviously supersede partial nickname match, so we would need to adjust
the scoring accordingly:
if (nick == aSearchString)
return BEST+2;
if (nickIndex == 0)
return BEST+1;
However, I'm not convinced yet if making initial nickname matches rank
higher than anything else will really work out well, e.g.:
Card1: Display Name="Tom" popularityIndex=10
Card2: Nickname="TomFoo" popularityIndex=5
Card3: Nickname="TomBar" popularityIndex=4
Searchphrase: "Tom"
Autocomplete result:
Card2 (partial nickname match, pi=5)
Card3 (partial nickname match, pi=4)
Card1 (full display name match, pi=10)
So I'm not sure if all results with partial matches on nickname should
rank higher than full match on display name; should they? (I think not).
Worse, PLEASE let's be aware that any forced top scorings that are not
based on frecency will further undermine even the current rudimentary
frequency implemtation of "popularityIndex":
Card1: Display Name="Tom" popularityIndex=1000
Card2: Nickname="TomFoo" popularityIndex=5
Card3: Nickname="TomBar" popularityIndex=4
Card4: Nickname="Tim" popularityIndex=6
Card5: Nickname="TD" popularityIndex=7
Searchphrase: "T"
Autocomplete result:
(all partial nickname matches top-listed, ordered by popularity:)
Card5
Card4
Card2
Card3
(then, potentially far down the list:)
Card1 (initial Display name match; popularityIndex=1000(!))
So in this case, even for partial nickname matches from single-
character(!) search phrase, ALL partial nickname matches will be
toplisted (although they are not popular at all, and the partial match
on their nicknames is entirely insignificant!), whereas highly popular
Card1 with an inital match on Display name will rank lower than all the
insignificant matches.
Undermining "frecency"-based sorting more is imo a slippery approach
because we'll never find a one-for-all algorithm to predict which
address the user actually wants, but "frecency" (linked up with the
actual user input) will certainly be one of our best bets. I think.
These things are actually pretty complex...
Please correct me if I'm wrong, but I conclude that it'll be safer if we
just fix the main usecase of this bug, which is FULL nickname matches;
let the rest be handled by our existing algorithm. So I suspect that
this should be sufficient:
if (nick == aSearchString)
return BEST+1;
Also, since full nickname matches (per inherent design) must really
always be toplisted without exception (regardless of any other sorting
algorithms we might think of), I wonder if we should leave some room in
the score for pushing other matches into the "best+" range:
if (nick == aSearchString)
return BEST+100;
Further technical reviews might want to test and improve performance
against large ABs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/956618
Title:
Nickname not over-riding names in email address
To manage notifications about this bug go to:
https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
Nit: While we are here, can you please fix this comment: http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/nsAbAutoCompleteSearch.js#152 > 152 // ":xx:", "jd", "who". 152 // ":xx", "jd", "who". -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
(In reply to Michael Gile from comment #80) > and one should not have to wait .5s for the autocomplete to prefill to hit > tab. Michael, that's Bug 1012397. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
(In reply to Thomas D. from comment #88) > Comment on attachment 8557496 > Patch v2 > > Review of attachment 8557496: > - > > True, but still not sufficient for ensuring absolute top ranking for *full* > nickname matches over *partial* nickname matches, e.g.: > Card1: Nickname="foo" (nick==searchphrase; nickIndex==0) > Card2: Nickname="foobar" (nick!=searchphrase; nickIndex==0) > Searchphrase: "foo" > > Autocomplete result (wrong): > Card2 (partial nick match) > Card1 (full nick match) That result can occur e.g. when Card2 has a higher popularityIndex than Card1. It shouldn't occur because full nickname matches (by inherent design) must supersede any other match, regardless of popularity. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
(In reply to Magnus Melin from comment #92) > Comment on attachment 8557496 > Patch v2 > > Review of attachment 8557496: > - > > Hmm, Thomas has some point. So here's what I think we should do: > > if (nick == aSearchString) > return BEST+1; > if (nickIndex == 0) > return BEST; Cool! Looks like it could be an elegant solution to problems mentioned in my comment 88. Thanks, great teamwork! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 235101]
*** Bug 1036626 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/235101 Title: Can't select/copy/paste address block from Address Book in Thunderbird To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/235101/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1347305]
Adding relevant search words to summary - was too hard too find! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1347305 Title: Address fields are grey when composing messages To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1347305/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 10883]
Hi! You are receiving this message because you are cc'ed on
Thunderbird's Bug 216132: Toggle mail compose between Plain text and
HTML. As announced in comment 65, and in support of weirdkeen's most
welcome initiative to finally tackle this bug (see comment 67), I'm
duping this bug against bug 140800, which is the very same request per
its current summary and content ("switch for plain text/html in compose
window").
This bug 216132 currently has 52 votes (and 59 votes on bug 140800).
Unfortunately bugzilla does not allow merging of votes along with
duping, therefore:
-> PLEASE VOTE FOR BUG 140800 NOW so that your vote can be transferred to and
counted for bug 140800.
To vote, click on the link [1] below, ensure the checkbox for bug 140800 is
ticked and don't forget to confirm your vote with "Change My Votes" button at
the bottom of your personal votes page. Tia.
[1]
https://bugzilla.mozilla.org/page.cgi?id=voting/user.html&bug_id=140800#vote_140800
Fyi, you'll probably be aware that TB is now maintained mostly by the volunteer
community, so we need your help to keep TB going. Can you help in any of the
following areas?
- bug triaging
- bug fixing
- documentation
- translation
- etc.
-
(In reply to Thomas D. (away till 31st January) from comment #65)
> (In reply to Thomas D. from comment #54)
> > How is this different from bug 140800?
> >
> > If they are the same, that would make this quite a much-wanted request with
> > 100 votes and 23 dupes...
>
> I have not heard any objections against merging this into bug 140800 as they
> are essentially the same. That merge definitely needs to happen (but I don't
> have time right now):
>
> Next Steps for this bug:
> * Resolve this bug 216132 as a duplicate of bug 140800, with an explanatory
> comment asking users to vote for bug 140800 if they want their vote for this
> bug to be counted (transferring votes)
done.
> * Resolve each of the 12 duplicates of this bug 216132 as a duplicate of bug
> 140800, and also ask users to vote for bug 140800 if they so wish
> (transferring duplicates)
still to be done, plus check for "dupes of dupes" and also re-dupe them
to bug 140800.
*** This bug has been marked as a duplicate of bug 140800 ***
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/10883
Title:
Stuck in proportional font mode
To manage notifications about this bug go to:
https://bugs.launchpad.net/thunderbird/+bug/10883/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 235101]
*** Bug 733062 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/235101 Title: Can't select/copy/paste address block from Address Book in Thunderbird To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/235101/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
Sorry, the flags should have another comment, so I'll toggle them back and forth once more to get that right. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
(In reply to Thomas D. from comment #45) > (In reply to Deven Corzine from comment #43) > > This worked in Thunderbird 2, which means it's a regression bug, not an > > Fwiw, notwithstanding the annoyingness of this bug, it is NOT a regression. > I just tested this on TB version 2.0.0.24 (20100228), and nicks do NOT get > absolute precedence in composition's recipient autocomplete (but it's easy > to get fooled into thinking they do). > > I tested with this scenario (basically): > > Card1: > firstname: n1n > email: a...@asdf.com > nick: n2n > > Card2: > firstname: foo > email: a...@asdf.com > nick: n1n > For reproducing this bug, create two new cards to ensure that both cards have same value for popularityIndex, otherwise the correct card might appear toplisted but for the wrong reasons. > > STR > 1 compose new msg > 2 in TO recipient field, type "n1n" > > Actual Result: > - card 1 is at top of autocomplete list > - ... > > Expected Result: > - card 2 having fullstring match of nick should be at top of autocomplete > list -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
(In reply to j.mccranie from comment #62) > Now I can't send to a list! j.mccranie, problem appreciated, but it's not related to this bug so let's be focused. Feel free to file a new bug if this isn't on record yet. But I think I've seen a recent bug for that which I can't find right now. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
*** Bug 323364 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
(In reply to yanlu from comment #64) > (In reply to yanlu from comment #60) > > I have a quite large email adress book : 525 "collected adresses" and 15000 > > "personnal adresses". Thunderbird is badly impacted with the TB31 email > > autocompletion behaviour : > Seems fixed in TB 31.1.1 with > https://bugzilla.mozilla.org/show_bug.cgi?id=984875 fix. Yanlu, thanks for reporting back with user feedback which is generally welcome. However, the autocomplete problems you mention are not related to this bug, so let's avoid them here. Moreover, let's avoid unspecified general statements like "Seems fixed" which might easily be misunderstood to mean this bug here is fixed, which is NOT the case. But yes, we're in the process of fixing things in recipient autocomplete; some fixes have already been released, and more pending, e.g. Bug 970456. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
(In reply to :aceman from comment #71) > The infrastructure created in bug 970456 should make it easy to prioritize > anything we want. Unless deciding about the priority of each contact is slow > and so unnacceptable for large result sets. I want to believe so too, but aren't we sorting plain *results* there *after* the fact (aka email addresses, potentially two from each card), whereas for nickname we need to retrieve that at a much earlier point where we still have access to the card (and going back from email to card would be error-prone in current flawed design of AB)? In fact, since a card can have 2 mail addresses, both of them might have to be toplisted in case of nickname match, primary address first. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
Aceman, Suyash, sorry for nagging, but given the added importance of this bug for the current autocomplete UX, could you answer to my Comment 59? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
OT: (In reply to :aceman from comment #68) > > > Now I can't send to a list! > > j.mccranie, problem appreciated, but it's not related to this bug so let's > > be focused. Feel free to file a new bug if this isn't on record yet. But I > > think I've seen a recent bug for that which I can't find right now. > > Should have been fixed in TB31.1.1 via bug 1060901. Thanks for the reference on that mailing list bug, and from there, the other one I had in mind was Bug 1008718. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
(In reply to José Josephus from comment #73) > Such an incredible waste of resources! [...] Getting carried away > with complicated search methods as described above is complete > nonsense! I've addressed the obvious social and factual shortcomings of that comment via private mail, including a link to https://bugzilla.mozilla.org/page.cgi?id=etiquette.html. (In reply to Tilmann Reh from comment #74) > José, just because you don't know and/or use nicknames doesn't mean they are > obscure, useless or don't make any sense. Particularly for me, nicknames (in > most cases just the initials) are the (by far!) preferred and fastest way to > enter a recipients address. Just enter two or three letters and pick the > adress from the upcoming (very short) list. This has always worked perfectly > fine for many years (since early Netscape), until it was broken due to some > "enhancements" to the search function. We just want that to be repaired. +1. Thanks Tilmann. We've heard your plea and we're working to repair that in Bug 970456, while preserving the actual "enhancements" of the search functions which we introduced to fix other bugs and cater for legitimate user expections. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
Oh, and somewhat contrary to comment 0, my understanding of this bug is that most importantly, we want to toplist autocomplete results where nickname==searchstring (full string match). Haven't thought about partial nickname matches much, but strongly suspect we shouldn't undermine popularity more than necessary, so just toplisting full string matches would suffice for this bug (ignore other sorting suggestions found in comment 0). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 956618]
Aceman, I think this shouldn't be too hard and will be very similar and in same code area as your sophisticated patch in Bug 984875, attachment 8428850. My comment 50 and comment 51 also provide a starting point how this could be done. Perhaps the combination of your insight and my starting points might enable you to come up with a draft patch here? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/956618 Title: Nickname not over-riding names in email address To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/956618/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 10883]
How is this different from bug 140800? If they are the same, that would make this quite a much-wanted request with 100 votes and 23 dupes... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/10883 Title: Stuck in proportional font mode To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/10883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 10883]
*** Bug 773135 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/10883 Title: Stuck in proportional font mode To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/10883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 397574]
*** Bug 520953 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/397574 Title: Encoding problems after switching the layout To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/397574/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 397574]
*** Bug 767031 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/397574 Title: Encoding problems after switching the layout To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/397574/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 397574]
Search for related bugs or duplicates (bravely assuming they mention "Layout" in bug summary): :thun,mail [layout https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%3Athun%2Cmail%20[layout -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/397574 Title: Encoding problems after switching the layout To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/397574/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 397574]
Alta88 claims in Bug 531397 Comment 12 that his MoreLayoutsforThunderbird addon (1) fixes many bugs that occur when changing View > Layout. Maybe he can help to fix this longstanding bug (15 duplicates since 2004), or somebody can get some coding inspiration from his addon. (1) https://addons.mozilla.org/de/thunderbird/addon/morelayouts/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/397574 Title: Encoding problems after switching the layout To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/397574/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 397574]
See also: Bug 718306 - Changing layout breaks with Mail Summaries and/or Conversations Bug 531397 - switching Layout modes breaks feed content display entirely until restart -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/397574 Title: Encoding problems after switching the layout To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/397574/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 699922]
can't find dupe for TB. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/699922 Title: Thunderbird displays notification on wrong monitor To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/699922/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1085]
I suppose there must be a lot of reports on this on getsatisfaction, but I don't have time to research. If you find some, please tag them "bug 167010" so that URL of this bug will expose them. Then, we need to label one of these reports canonical. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1085 Title: selecting text in full header mode fails To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1085/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1085]
While this bug may not technically depend on Bug 136897, and may differ in other ways, they are related in that they address a similar type of problem in a similar part of the UI. Unfortunately bmo doesn't have many ways yet of expressing such relations. Let's keep a link then, in see also. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1085 Title: selecting text in full header mode fails To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/1085/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 261595]
*** Bug 765610 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/261595 Title: Thunderbird corrupts Mailbox when hd is full To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/261595/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 261595]
*** Bug 599664 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/261595 Title: Thunderbird corrupts Mailbox when hd is full To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/261595/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 261595]
Adding some searchwords for better retrievability. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/261595 Title: Thunderbird corrupts Mailbox when hd is full To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/261595/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 235101]
*** Bug 849506 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/235101 Title: Can't select/copy/paste address block from Address Book in Thunderbird To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/235101/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 711314]
Wow, what a confusion here! (In reply to Mike Cowperthwaite from comment #42) > This bug morphed, unacceptably in my view, starting at comment 27. That > problem is/was entirely different from the (Mac-only) problem originally > reported here. +1 > The "new" problem, brought on by the "fix" for bug 128124, is that the > mailing list dialog is modal (and is present on all platforms); the actual bug > for fixing that problem is bug 135126 (and see also bug 115904). > Since the modal dialog effectively prevents anyone from testing if the > original bug still exists, I'll be adding a dependency. +1 (In reply to Wayne Mery (:wsmwk) from comment #55) > as a result of the blocker, as a practical matter, I don't see much value to > keeping this open, because prior to comment 27 there is no testcase, let > alone a reduced testcase, and no clear steps that others can replicate. > ... > Unless we want this to be the cesspool for all drag and drop bugs with no > testcases or poorly formed reports - in which case the currently vague > summary needs improvement. But given this bug's ragged long history I'd > sooner pick a newer, shorter, more clearly worded bug. +1 I see two ways of clearing this up: 1) Morph this bug back into a MAC-only bug to be revisited after fix for bug 135126, with a crystal clear summary, and an entry in Whiteboard pointing to an authoritative comment explaining the matter Or 2) Shut this bug down and create a new MAC-only bug to be revisited after fix for bug 135126, with a crystal clear summary, and description pointing to those other bugs like bug 135126 Before doing that, I'd like two pieces of information (A+B): A) (In reply to James Rome from comment #69) > But on a Mac, it does NOT open in a separate window! So you cannot drag and > drop from your main address book. > TB needs to override the Mac "style" guidelines and use a separate window. As a windows user, I'm confused bc comment 0 suggests the presence of a Mailing List *window* on MAC, whereas comment 69 denies the same. James, can you "add an attachment" to this bug, with a screenshot showing the current design of Mailing List Properties dialog on MAC? Does the window/non-window design of MAC play any role for this bug (I think not)? B) Do we have a bug for comment 68 (which is clearly different from this bug, but perhaps it is blocking bug 135126)? (In reply to Ann-Marie from comment #68) > Go to address book. > Open one of the address lists, new window "Mailing List" with List name. > There is ONE open line at the bottom waiting for the next entry. > Drag and drop an email address from another source such as an email message > content in one of your email folders. > The drag and drop email occupies the open line on the Mailing List as > expected. > Drag and drop another to add to the list and there is no open line to drop > it in. > > You have to click on the Mailing list and manually scroll down to open a new > empty line. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/711314 Title: Address Book - Can't drag and drop contacts to list To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/711314/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 711314]
Adding more prominent pointer to the Thunderbird equivalent of this bug (keeping which might be helpful to avoid duplicates in TB product). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/711314 Title: Address Book - Can't drag and drop contacts to list To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/711314/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 711314]
(In reply to Thomas D. from comment #71) > Adding more prominent pointer to the Thunderbird equivalent of this bug > (keeping which might be helpful to avoid duplicates in TB product). I fell prey to the confusion myself. TB bug 282841 is the equivalent of Mailnews Core bug 135126, so it's not related to the original MAC problem of this bug, and the see-also pointer will just undermine our efforts to isolate the MAC problem in this bug as proposed in comment 70. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/711314 Title: Address Book - Can't drag and drop contacts to list To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/711314/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 98596]
Assigned to: David :Bienvenu - does that still apply? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/98596 Title: Reply and Forward buttons don't work when opening a rfc822 attachment in a new window To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/98596/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 848183]
*** Bug 260556 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/848183 Title: RFC822 Attachments and .EML files cannot be moved to folders To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/848183/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 848183]
*** Bug 724771 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/848183 Title: RFC822 Attachments and .EML files cannot be moved to folders To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/848183/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 848183]
*** Bug 347647 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/848183 Title: RFC822 Attachments and .EML files cannot be moved to folders To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/848183/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 848183]
*** Bug 259709 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/848183 Title: RFC822 Attachments and .EML files cannot be moved to folders To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/848183/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 848183]
*** Bug 249750 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/848183 Title: RFC822 Attachments and .EML files cannot be moved to folders To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/848183/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 848183]
And as Mozillians never got round to fix those thousands of acknowledged bugs, and some were even bold enough to declare that TB's users are happy with the status quo, nobody remembered all those age-old bugs, while the dupes gathered from all corners of the world and lived happily everafter... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/848183 Title: RFC822 Attachments and .EML files cannot be moved to folders To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/848183/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 848183]
*** Bug 542038 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/848183 Title: RFC822 Attachments and .EML files cannot be moved to folders To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/848183/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 848183]
(In reply to Brian Murrell from comment #19) > Has this ticket gone moribund for a new ticket covering the same general > features? No, this ticket is still alive in the mailnews core component shared by SeaMonkey and TB. Otherwise, I suppose *all* tickets are now moribund unless volunteers like you and me volunteer to fix them. Brian, do you have some coding skills to try this? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/848183 Title: RFC822 Attachments and .EML files cannot be moved to folders To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/848183/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 848183]
*** Bug 232519 has been marked as a duplicate of this bug. *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/848183 Title: RFC822 Attachments and .EML files cannot be moved to folders To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/848183/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 711314]
As announced and explained in comment 70, I will close this bug because it has lost focus of the original MAC-only problem and has become too messy to maintain. * The original MAC-only problem of this bug has been re-filed as bug 814342. That problem was observed *before* bug 128124 made the list properties dialogue modal on all OS, so it cannot currently be tested and needs to be revisited after fix for bug 135126. * Bug 135126 (and its TB-twin bug 282841 currently kept open as a duplicate collector) covers the current problem on *all* OS that it is generally not possible to drag & drop cards into the List properties dialogue because the dialogue window is modal. Todo: - check if different problem of Comment 68 is covered by its own bug (that's a problem of dragging *text* into the list properties dialogue, and it doesn't create new lines for subsequent addresses as expected) - revisit & sort out duplicates of this bug and move them to the appropriate current bugs. Due to the morph-mess in this bug, I'd expect some of them to be dupes of bug 135126 rather than bug 814342. *** This bug has been marked as a duplicate of bug 814342 *** -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/711314 Title: Address Book - Can't drag and drop contacts to list To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/711314/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
