6.08 KB, image/png
2.38 KB, patch
|Details | Diff | Splinter Review|
9.79 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168pre) Gecko/20091027 Shredder/3.0pre If you cancel creating any accounts after launching a new Shredder profile, when you then click on "Write," you are given only the options of creating a "Blog & News Feeds" or "Newsgroup account". There is no option of creating an email account. Reproducible: Always Steps to Reproduce: 1. Create a new account and launch Shredder with it 2. Cancel on all the new account setup prompts till all you have is the main Shredder interface 3. Click the "Write" toolbar button 4. Notice that "New Account Setup" wizard appears and DOES NOT provide an option of setting up an email account. See attached image.
Component: General → Account Manager
Created attachment 408749 [details] New Account Wizard on clicking "Write" button. Email option missing.
Conveniently, http://mxr.mozilla.org/comm-central/source/mailnews/base/prefs/content/accountUtils.js#113 does have a param to specify the function you want to have called for wizardOpen.
Keywords: polish → regression
Version: 3.0 → Trunk
This bug is likely to be hit by folks trying out Thunderbird for the first time, and the consequence could be that they'd just give up on Thunderbird rather than figuring out how to workaround the problem, which would be unfortunate. As such it would be very nice to have a fix (which, as philor points out, should be very easy). That said, I suspect it's a moderately unusual sequence of user actions, and it's trivial to workaround by simply creating an account using File -> New -> Mail Account. So I think we probably wouldn't block on this. Adding clarkbw to the CC in case he disagrees.
Flags: blocking-thunderbird3? → blocking-thunderbird3-
I think we should probably relnote it, however.
cc'ing rebron due to the relnote.
This would be good to get fixed. New users to Thunderbird have little to no investment in the application and as such we can't really expect that they would try a workaround.
If this isn't fixed, it will be better to disable "Write" if there is no mail account configured, so as to force users to try something else (file > new > mail account or Tools > account settings). Showing the news & rss setup really has a too big potential for confusion and frustration. (In reply to comment #2) > Conveniently, > http://mxr.mozilla.org/comm-central/source/mailnews/base/prefs/content/accountUtils.js#113 > does have a param to specify the function you want to have called for > wizardOpen. Phil, I understand from http://mxr.mozilla.org/comm-1.9.1/source/mailnews/base/prefs/content/accountUtils.js#171 that there must be a function by the name wizardOpen(...), but I can't find that function anywhere on mxr. Can you enlighten me a little as to where that function is, what kind of parameters wizardOpen can take in line 113 as above, or how it works?
In Bug 529499, comment #4, Bryan proposed blocking on this, which would also take the worst out of bug 529499: > I could see possibly blocking on getting bug 524863 fixed as the write button > is in a number of places and we don't want to default to the old wizard. Where the old wizard is really "the wrong trap door wizard" as it doesn't let you set up the mail account which you need for "Write", and canceling that wrong thingy is very hard if you don't concentrate really well. I think we're all getting bored by all the bugs which we know need to be fixed and we'd even want to fix but we can't fix them nicely because of the over-due release. So for a change, I'll propose the route of least resistance for this bug: Proposed fix: - instead of fiddling with the account setup selection dialogue to add the missing email option - at the place in code where the old, wrong, rss+news setup dialogue get's called - call the mail account quick setup dialogue instead (so hopefully this would be just 2 lines of code) In fact, this might be the proper fix for this, given the scenario of this bug: - no accounts at all - user presses write We can assume with a relatively high probability that user want's to write an email, for which he needs a mail account. (It seems far less likely that user would click "write" to compose to a news server that hasn't even been set up yet). I can't think of any other scenarios where offering the mail quick setup on "Write" would be the wrong thing if there's no accounts (perhaps if right after install, you set up ONLY a news account and delete the email address from it). Otherwise, as soon as there is any mail or news account, write will always compose.
Flags: blocking-thunderbird3- → blocking-thunderbird3?
(In reply to comment #9) > In Bug 529499, comment #4, Bryan proposed blocking on this, which would also > take the worst out of bug 529499 > > Proposed fix: > - instead of fiddling with the account setup selection dialogue to add the > missing email option > - at the place in code where the old, wrong, rss+news setup dialogue get's > called... ... when we press write, of course, not in general > - call the mail account quick setup dialogue instead > (so hopefully this would be just 2 lines of code)
Forgive me if I'm not understanding your discussion correctly, but why not just call the dialog from: Tools --> Account Settings... --> Account Actions --> Add Other Account... Shouldn't that be simple enough and cover all bases?
I talked to IU via mail and he was really trying to say is the same as my proposed fix in comment #9: When there's no accounts, and user clicks "Write", > - let's call the Quick "Mail Account Setup" dialogue (mail autoconfiguration, instead of rss & news setup wizard) > (so hopefully this would be just 2 lines of code)
Assignee: nobody → dmose
Flags: blocking-thunderbird3? → blocking-thunderbird3-
Created attachment 413689 [details] [diff] [review] patch, v1 First cut; the lowest-risk patch we could take. This does what was suggested in earlier bug comments, and it improves the situation, but if the user cancels out of the wizard spawned by the compose window, she's back where she started: in the identity-less compose trap. I'll work on putting together something better, but since this is a ride-along, best get started on this version now...
Attachment #413689 - Flags: review?
Comment on attachment 413689 [details] [diff] [review] patch, v1 Doh! Bogo-patch-version. Better one coming up.
Created attachment 413693 [details] [diff] [review] patch, v2 [checked in in comment 19]
Comment on attachment 413693 [details] [diff] [review] patch, v2 [checked in in comment 19] looks OK on first look.
Attachment #413693 - Flags: review? → review?(bienvenu)
Comment on attachment 413693 [details] [diff] [review] patch, v2 [checked in in comment 19] I had to cheat and try this on the trunk, but it works there.
Comment on attachment 413693 [details] [diff] [review] patch, v2 [checked in in comment 19] seems good
Attachment #413693 - Flags: ui-review?(clarkbw) → ui-review+
Attachment #413693 - Flags: approval-thunderbird3? → approval-thunderbird3+
Patch v2 pushed to comm-1.9.1: http://hg.mozilla.org/releases/comm-1.9.1/rev/247387d193ac
Patch v2 pushed to COMM1915_20091112_RELBRANCH: http://hg.mozilla.org/releases/comm-1.9.1/rev/3047465d50a0
Whiteboard: [tb3ride-along] → [tb3ride-along][fixed RC1 build 3]
There's the following problem with Patch v2: Prior to this patch landing, dismissing the account setup dialog, that appears after clicking the Write button (i.e. you've still elected not to setup an account), would make the Write dialog also disappear. With this path, however, the Write dialog remains. This makes no sense, since it's not really usable: (1) impossible to type in the message pane; (2) impossible to save. If one leaves that Write dialog open and again clicks the Write button, this process can be repeated, leaving many Write dialogs open. I believe the Write dialog should be dismissed as before. I know we can assume no user will ever be that thick, but do we really want to go there? :-)
You're right that the old behavior is indeed more desirable, but the existing APIs didn't make it easy to do that. I've got a patch in progress that will do what you propose, which we could conceivably take for 3.0.x. My gut feeling is that what we've got now is good enough for branch, as long as we actually do the right thing on trunk (i.e. for 3.1).
Created attachment 413848 [details] [diff] [review] detect setup failure, v1 (WIP) This patch needs to be applied on top of the thing that landed on branch. It's mostly done, but it doesn't actually work right yet, so it needs some more debugging.
Whiteboard: [tb3ride-along][fixed RC1 build 3] → [tb3ride-along][fixed RC1 build 3][fixedtb301]
status-thunderbird3.0: --- → .1-fixed
Whiteboard: [tb3ride-along][fixed RC1 build 3][fixedtb301] → [tb3ride-along][fixed RC1 build 3]
Dan, can you take the follow-up fix to a different bug, so that we can close this bug as fixed for 3.0 (which it essentially was) and then allow us to track the landing of the follow-on for 3.1 or a 3.0.x release separately?
I've separated out the follow-ups (comment 21 through 23) into bug 538931. Therefore closing this bug as fixed for TB 3.0 (which is when the main patches landed).
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3
While this was supposedly fixed for Thunderbird 3.0, I can actually reproduce this bug (as described in comment 0) in Thunderbird 3.1, as well as in the current "Earlybird" release. (Those are the only thunderbird versions that I have handy to test.) I'm assuming this *was* actually fixed at some point, so rather than reopening this bug, I filed Bug 672963 to track this. (If it'd be more appropriate, though, feel free to reopen this bug & dupe the new bug to this one.)
Actually, did this bug's fix ever land on comm-central? I only see commit messages here for comm-1.9.1.
+ // The fix that lands on the trunk will do better. probably refers to the WIP patch for the trunk, which did not land.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(duping my spun-off bug to this one)
This wasn't a simple landing as I'd expected, moving out to 9.
tracking-thunderbird8: + → -
tracking-thunderbird9: --- → +
tracking-thunderbird10: --- → +
tracking-thunderbird9: + → -
I am implementing a fix in bug 713277, where I actually hide the "Write a new message" action in the account central when there are no accounts set up. See e.g. http://dl.dropbox.com/u/2301433/Screenshots/DailyNullNull.png in there. Would that change the situation here in any way?
Well, it doesn't look like it disables the "Write" button which is what this bug is about. Maybe it should just disable all toolbar buttons.
I must have overlooked this is talking about the toolbar button. Disabling buttons would be nice but can't be done until bug 713277 comment 19 is solved. I am not sure the account central would refresh once an account is created so that the code to enable the buttons again could run.
(In reply to :aceman from comment #35) > Disabling buttons would be nice but can't be done until bug 713277 comment > 19 is solved. I am not sure the account central would refresh once an > account is created so that the code to enable the buttons again could run. Alternately, the Write button could just open up the account creation window as the patch v2 was going to do so.
Assignee: mbanner → nobody
tracking-thunderbird10: + → -
Isn't this actually the same as bug 745344 which has a patch too? Bwinton, you had some issues with my implementation there, can you see if the patch here is better? Also, did any of the patches here land as there is confusion in the comments.
Removing relnote keyword from bugs that are no longer significant or not needing to be mentioned in the release notes.
But this is does not seem fixed or mitigated...
(In reply to :aceman from comment #39) > But this is does not seem fixed or mitigated... That's true, but the majority of users won't be going to this route to begin with, they will be using the prompts that come up.
Created attachment 8738230 [details] [diff] [review] disable Write Both the patches seem too hacky and complicated to me. I'd rather disable the Write buttons until we have som accounts. Would this work?
Attachment #8738230 - Flags: review?(mkmelin+mozilla)
Comment on attachment 8738230 [details] [diff] [review] disable Write Review of attachment 8738230 [details] [diff] [review]: ----------------------------------------------------------------- I suppose so. I'll note that the Chat icon is active, and if you click it there's a really nice "hey you don't have any accounts" message showing up. We could add something similar on the main page for mail (and other accounts).
Attachment #8738230 - Flags: review?(mkmelin+mozilla) → review+
Is what you mean covered by bug 746095? Do you think we should do anything more here?
You could do it there yes. I think disabling Write makes sense since it's also shown in some places where there's no place to show info, like the address book.
Any reason the disable write patch never landed (it's a lot better than bringing up out of context account creation windows)? Also, send later needs to be handled; patch attached. Feel free to incorporate into the existing patch.
Created attachment 8838804 [details] [diff] [review] later.patch
Attachment #413693 - Attachment is obsolete: true
What is the problem with Send later? How do you trigger it?
In a brand new profile, if you create a chat account and go offline it throws. I was also considering removing Local Folders from feed account creation. The issue happens if there isn't an Outbox, iirc.
Shouldn't it then return 'false' from: Components.classes["@mozilla.org/messengercompose/sendlater;1"] .getService(Components.interfaces.nsIMsgSendLater) .hasUnsentMessages() ? Also why does chat trigger Send later?
Ah, going offline checks if there are messages to be sent.
Can I persuade you to make hasUnsentMessages return false at https://dxr.mozilla.org/comm-central/rev/6ee27a7af6cd3e7bd25f392048fd40160910275a/mailnews/compose/src/nsMsgSendLater.cpp#703 if there is no unsent folder, similarly to when there are no accounts? Then we do not need the catches.
Yeah, that is the better way.. But I don't think it's just that, it's merely creating an instance of nsIMsgSendLater that's a problem (iirc, the try catch was done quite a while ago). I'll take a look and file a new bug, it shouldn't hold up the patch here. It was related only in that there are little things that assume identities and outboxes and email things that shouldn't bother non email account types.
Created attachment 8838894 [details] [diff] [review] disable Write v1.1 The patch needed unbitrotting.
Yes, thanks. Please copy our comments to the new bug. I'll land what is done here.
Keywords: helpwanted → checkin-needed
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago → 11 months ago
Resolution: --- → FIXED
Target Milestone: Thunderbird 3 → Thunderbird 54.0
You need to log in before you can comment on or make changes to this bug.