[Bug 1085]
For an impression how much users want to select and copy from inbound message headers, see the ancient parent bug: Bug 61497 - [SM] Can't select text in message headers / copy subject **42 duplicates** were filed against that bug, most of them demanding that *all* of the headers should be selectable for copying, i.e. including *recipients*. However, bug 61497 only fixed half of the problem (selecting subject), the other half was moved to this bug 167010 (originally `SeaMonkey`, then `MailNews Core`, now `Thunderbird`). -- 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 356745 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 1085]
*** Bug 327621 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 1085]
Ryan, Alex, Henry - FYI wrt 114. 10+ duplicates atm, and 42 users CC'ed. If we could have a similar UX as in composition (easily selectable recipient pills), that would support this basic workflow for many users and avoid clumsy workarounds in 2023 (see user story for more). -- 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 1672139]
(In reply to Lebar from comment #51) > I've got some working code that I was going to submit to Phabricator, but I > thought that I would check here first on the protocol for context menu > changes. I opted for a "Reveal in Bookmark Tree" context menu entry in the > Library that would navigate to the appropriate place in the tree and then > highlight the entry in the right-hand panel (this seemed more sensible than > devising a new window just to show path). Hi Lebar, thank you for working on this, that's awesome! The behaviour sounds good to me (but it's not my call). The reporter of this bug, `Alex Faaborg [:faaborg] (Firefox UX) ` has provided some UX feedback in comment 6. `Reveal in Bookmark Tree` sounds exciting (as in 'Rise the curtain on this bookmark!'), but probably plain vanilla `Open Containing Folder` will be best for Windows (perhaps with variations like `Open Enclosing Folder` for other operating systems, but don't worry about that now). FF also uses `Open Containing Folder` for downloads when you hover the folder icon. > Is there some specific vetting process for menu/GUI changes? Are there other reviewers other than Mark or Marco that need to be included in the commits? Looking at the official owners and peers of the [Bookmark and History (Places)](https://wiki.mozilla.org/Modules/Desktop_Firefox#Bookmarks_.26_History) module, Mark or Marco should be the right people to review this. Just file your patch on phabricator first (make sure to link it to this bug by filling the bug number in the appropriate field) and set Mark as a reviewer. He will certainly advise you on the next steps. I work for Thunderbird, but I'd love to see this fixed as you can see from my comments here from time immemorial ;-) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1672139 Title: Add "Open Enclosing Folder" context menu to search results of bookmarks in the Library window (link to view/open containing folder, parent folder button) To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1672139/+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 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 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 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]
(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]
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 #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 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 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 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 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 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 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 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 #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, 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]
*** 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]
(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 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]
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]
(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 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 john(at)gmail.com 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 john(at)gmail.com 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 john(at)gmail.com [/] 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 john(at)gmail.com [/] v] |John private john.private(at)foo.bar | |John tertiary john.tertiary(at)asdf.com | +--+ - 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 john(at)fakemail.com [/] v] |*John john(at)gmail.com | |John private john.private(at)foo.bar | |John tertiary john.tertiary(at)asdf.com | +--+ - 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 john(at)gmail.com or edited Johnny Edited john(at)fakemail.com - 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 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 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]
*** 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]
(In reply to José Josephus from comment #73) rant Such an incredible waste of resources! [...] Getting carried away with complicated search methods as described above is complete nonsense!/rant end 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]
(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 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]
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 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]
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]
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 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 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.htmlbug_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 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 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 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=28t=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 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 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 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 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 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 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=nicknamex=1y=3style=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 10883]
(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) * 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) -- 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 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]
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
[Bug 711314]
I purged the unfit dupes of this bug and re-duped them to where they belong. -- 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]
Somebody should check to which of the current bugs the following link belongs, currently found in see-also of this bug: https://launchpad.net/bugs/711314 -- 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 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 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 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 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
