Closed
Bug 461130
Opened 16 years ago
Closed 13 years ago
Make exptoolbar's "Get Mail" button also handle synchronization for calendars
Categories
(Calendar :: Lightning Only, defect)
Calendar
Lightning Only
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: Fallen, Unassigned)
Details
(Whiteboard: [needs exptoolbar])
With the new toolbar [1], there will be a get mail button and a write button. It makes sense that this Get mail button doesn't only take care of getting mail but also takes care of synchronization for (at least, cached...) calendars. This means that if the Toolbar does have text-toolbarbuttons, then we might need to agree on a new name for it (i.e Synchronize,Sync,...). CC'ing Bryan for an opinion. [1] https://wiki.mozilla.org/Thunderbird:Toolbar
Flags: tb-integration?
Comment 1•16 years ago
|
||
It seems like a good idea in a perfect world. However, as long as Lightning uses 100% CPU for 10+ seconds to reload remote calendars, I'd rather have an independent reload-remote-calendars button in the calendar list.
Comment 2•16 years ago
|
||
Pete: is there a bug filed for this remote calendar reload problem? Fallen: Something that I think needs to be added to the logic of the refresh code is an idea of the users current visible context. If the person is looking at an email tab we should make the calendar refresh happen in the background as necessary. Similarly for mail, if a person is looking at the calendar tab we should be refreshing calendars as the priority and mail should be queued in the background. One possibility for the background refresh are to queue for downloading on IDLE (of either calendar or mail).
Reporter | ||
Comment 3•16 years ago
|
||
Yes, this makes sense. We do need to find out how we can actually throttle this in an appropriate way. Off the top of my mind I see no way to give the active context's operation precedence, other than doing calendar refreshes first and then when thats done to start mail requests. Daniel, mvl, others, any ideas how we could properly queue this?
Comment 4•16 years ago
|
||
I think the whole problem boils down to what we yet have to solve: (Re-)loading calendars should not block the UI responsiveness like it currently does. I think we need to thread calendar loading, might try nsIThreadManager et al. If the callbacks on UI (calIObserver) are causing the blocking (IIRC mvl experienced that some time ago), we should spend more time on properly (re-)implementing batch handling.
Comment 5•16 years ago
|
||
(In reply to comment #2) > Pete: is there a bug filed for this remote calendar reload problem? I think the main bug might be bug 387014 ("While Lightning reloads remote calendars, all Thunderbird windows are unresponsive").
Comment 6•16 years ago
|
||
blocking integration, although the UI threading responsiveness issue is scary in its implications, I expect.
Flags: tb-integration? → tb-integration+
Reporter | ||
Updated•16 years ago
|
Whiteboard: [needs exptoolbar]
Reporter | ||
Comment 7•13 years ago
|
||
Looks like the exptoolbar won't happen any time soon. We should re-evaluate when this changes.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•