logcat: http://pastebin.mozilla.org/2002174 I can choose other folders, and they load. But Inbox never does.
blocking-basecamp: --- → ?
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
This should most definitely be blocking. From the log (thank you!), the problem is that we have a queued operation on a header ('modtags') that is no longer known to the database. The _partitionAndAccessFoldersSequentially helper effectively asserts and dies, taking the mutex with it so nothing can ever happen in the inbox again. The actual 'modtags' operation expects and handles this situation, so it's mainly a question of exposing a null serverId in the case we're asserting on for modtags rather than dereferencing a null object and dying. I will also want to audit the other IMAP 'do' operations and add test cases that trigger this code path in both server-initiated and local move/delete operation varieties.
Status: NEW → ASSIGNED
QA Contact: nhirata.bugzilla → bugmail
Just a comment: I've had the same problem running Thunderbird 17.0 on both Windows 7 and Windows XP. When I reinstalled Thunderbird 16.02, everything worked fine.
blocking-basecamp: ? → +
Priority: -- → P2
Target Milestone: --- → B2G C3 (12dec-1jan)
Created attachment 693799 [details] [review] https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/102 Here's the fix and the unit tests previously described. I audited/filled out the IMAP usages. I implemented early bail logic if we end up with nothing to ask the IMAP server because it's not legal for us to ask to manipulate 0 messages. I also audited the ActiveSync usages. They are fine, although we may issue requests with 0 messages. I think this might be okay for ActiveSync? I am not sure, but it's not as major an issue as what I fixed in this bug because... We already have logic in place that eventually gives up on local operations after they experience multiple failures trying to run. The trick there is that we can only do that if the job completes with a failure status, and in this bug we were throwing an exception at a time/place where it would not be caught and converted into a job failure. If it turns out ActiveSync gets angry if we try and post a request to it with no actions taken, we should change this in a follow-up. The unit test work for these edge cases is more significant, especially for ActiveSync where the fake server would need to be enhanced I suspect.
Attachment #693799 - Flags: review?(squibblyflabbetydoo)
Attachment #693799 - Flags: review?(squibblyflabbetydoo) → review+
landed on gaia-email-libs-and-more/master: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/102 landed on gaia/master: https://github.com/mozilla-b2g/gaia/pull/7122
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
This issue does not reproduce with unagi, build ID 20121231070201
Status: RESOLVED → VERIFIED
(In reply to Mila Davydova from comment #5) > This issue does not reproduce with unagi, build ID 20121231070201 I just downloaded and installed Thunderbird 17.0.2 on a Windows 7 Starter OS. Same problem occurred; IMAP download on GMAIL inbox just spins and spins and spins -- never downloads. I uninstalled 17.02, reinstalled 16.02 -- still works fine.
This bug doesn't have anything to do with Thunderbird. You should file a separate bug.
This still occurs on nightly pvt. You would have to be on a build that has the master branch of gaia in order to verify that this is fixed. STR: 1. launch email 2. set up gmail account 3. open an email and mark it then move the file to starred 4. go to the starred directory 5. go back to inbox Expected: loading messages will finish Actual: stuck at the loading messages
Status: VERIFIED → RESOLVED
Last Resolved: 6 years ago → 6 years ago
Oh wait... this was fixed over 2 months ago? I guess I'm running into a regression then?
All kinds of stuff could break sync; it's almost entirely unlikely that it was this bug. I'm retitling the subject to help clarify what the actual problem was.
Summary: Email app stuck loading Gmail inbox, never gets past "loading messages" → [email] queued header operation on a message no longer in the database breaks sync
I have had the same problem -- gmail accounts inboxes never load -- for all versions of Thunderbird 17.0 - 17.02. I'm currently running 16.02, which works fine. This bug -- whatever it is -- is not fixed.
(In reply to clanier00 from comment #11) > I have had the same problem -- gmail accounts inboxes never load -- for all > versions of Thunderbird 17.0 - 17.02. I'm currently running 16.02, which > works fine. This bug -- whatever it is -- is not fixed. This bug still has nothing to do with Thunderbird; bugs for Thunderbird live under the Products "Thunderbird" or "MailNews Core". I'm removing you from the cc to help avoid further confusion. Please check out https://support.mozillamessaging.com/en-US/home for Thunderbird support; there is probably something wrong with your profile/account setup, and you will want to either re-create the account or the profile.
Attachment mime type: text/plain → text/x-github-pull-request
You need to log in before you can comment on or make changes to this bug.