maemo.org Bugzilla – Bug 4024
Modest background process pops up Edit Account dialogs
Last modified: 2009-10-22 21:41:33 UTC
You need to log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: 4.1.3 (5.2008.43-7) STEPS TO REPRODUCE THE PROBLEM: Leave the tablet in an area with non-perfect network connectivity and Modest mail check process running in background. EXPECTED OUTCOME: Modest should check for email whenever connection is available. It should handle connection failures gracefully, at any stage of account authentication and inbox download process. ACTUAL OUTCOME: When Modest's connection to the mail server fails at a certain stage, Modest pops up the Edit Account dialog and hangs waiting for user input. If the user cancels the dialog or OKs it without making any changes, Modest will pop up the same dialog at the next mail check, even if the network connection is no longer faulty. The only way to rectify this problem is to manually CHANGE one of the account fields and THEN OK the dialog. In this case, Modest will report "Settings saved" and continue normal operation. OTHER COMMENTS: This bug report is labeled to have major severity because it once again prevents Modest (the default, Nokia-provided mail application) from being used as a mail client on daily basis. REPRODUCIBILITY: always User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Confirming. Happens often enough to be annoying.
And fixed :-). The problem was basically a condition that was placed in the wrong place. The code was like else if (error->code == TNY_SERVICE_ERROR_AUTHENTICATE) { modest_platform_run_information_dialog (NULL, prompt, TRUE); /* Show the account dialog if it was wrong */ if (error->code == TNY_SERVICE_ERROR_CONNECT || error->code == TNY_SERVICE_ERROR_AUTHENTICATE) show_wrong_password_dialog (account); and should be like else if (error->code == TNY_SERVICE_ERROR_AUTHENTICATE || error->code == TNY_SERVICE_ERROR_CONNECT) { modest_platform_run_information_dialog (NULL, prompt, TRUE); /* Show the account dialog if it was wrong */ if (error->code == TNY_SERVICE_ERROR_AUTHENTICATE) show_wrong_password_dialog (account); which means that only authentication errors will show the dialog So Andre this is fixed in the repos, don't know when it will be available though :(
(In reply to comment #2) > And fixed :-). The problem was basically a condition that was placed in the > wrong place. Hurrah! Thanks, Sergio! PS: In the meanwhile, can we have a semi-official Modest release? Maybe to Extras-Devel, since Modest is supposed to be open sourced anyway?
I'm sorry, but I don't know this kind of information.
Now that was a quick fix. Cool, thanks! (In reply to comment #2) > So Andre this is fixed in the repos, don't know when it will be available > though :( Yes, the problem of having a seperate, internal Modest codebase currently... I hope Nokia will improve its openness the closer we get to Fremantle, but it's the same with release management: It's definitely not in the hands of the developers themselves. Let's hope that Nokia will ship a Diablo update soon.
This bug still occurs in Fremantle.
Technically speaking that's a different bug, but I've seen it too in Fremantle with my Gmail IMAP account, yes. Which account type do you use? Any specific testcase?
(In reply to comment #7) > Technically speaking that's a different bug, but I've seen it too in Fremantle > with my Gmail IMAP account, yes. > Which account type do you use? Any specific testcase? I have got a GMail IMAP account and a generic POP3 account. Both pop up the Edit Account dialog if there is a problem connecting. Thus, the problem is not specific to any account type. Simply showing the last update time in Modest using red color should suffice, IMHO.
I think this is actually a duplicate of bug 3728, unless the foreground/background distinction is important? Any objections resolving it as such?
(In reply to comment #9) > I think this is actually a duplicate of bug 3728, unless the > foreground/background distinction is important? Any objections resolving it as > such? It is actually more of a problem when it pops up from the background. But I agree that it shouldn't pop up in the foreground mode either.
(In reply to comment #9) > I think this is actually a duplicate of bug 3728, unless the > foreground/background distinction is important? Any objections resolving it as > such? I agree here. Thanks for finding that :) *** This bug has been marked as a duplicate of bug 3728 ***