Open Bug 432774 Opened 16 years ago Updated 2 years ago

Show a throbber while waiting for imip bar to load getItem results (delay,buttons)

Categories

(Calendar :: E-mail based Scheduling (iTIP/iMIP), defect)

Product:
Calendar
Component:
E-mail based Scheduling (iTIP/iMIP)
Type:
defect

Tracking

(Not tracked)

People

(Reporter: marcel, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

bug-432774-throbber-added
4.44 KB, patch
Fallen
: review-
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Build Identifier: 20080504

The Accept and Decline buttons on some of my invitations are only showing up after 5 seconds. The blue bar is present from the start, but the buttons show up late. I added the source of this specific invitation at the bottom.

During this delay, the there is activity on the network and the CPU usage shoots to 50% ( dual core 2.0GHz )

It seems like al events are effected with a high CPU load which causes a delay in showing the content of the message. This happens when switching between 5 emails with events in them. After the first 2 or 3, the next massage will have a delay in showing. It does not matter what sequence I use.

Disconnecting from the network removes all the delays, even the delay in the buttons.

Why and to what is it trying to connect? This is a normal local calendar, not a hosted one.

Reproducible: Always

Steps to Reproduce:
1. click on the email with the invitation

Actual Results:  
The blue bar appears immediately, and 5 to 6 seconds later the buttons

Expected Results:  
The blue bar and the buttons appear immediately.

I am part of the group@bdsolutions.co.za email. I am aware of the other bug that deals with the actual event being added to the calendar, but that does not deal with the delay in buttons and network activity.

BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN
VERSION:2.0
METHOD:REQUEST
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
BEGIN:VEVENT
ATTENDEE;CN="Mr F";RSVP=TRUE:mailto:XXXX@XXXX.co.za
ATTENDEE;CN=group@bdsolutions.co.za;RSVP=TRUE:mailto:group@bd
	solutions.co.za
CLASS:PUBLIC
CREATED:20080506T105808Z
DESCRIPTION:When: 15 May 2008 04:00 PM-06:00 PM (GMT+02:00) Harare\, Pretor
	ia.\nWhere: office\n\n*~*~*~*~*~*~*~*~*~*\n\n\n
DTEND:20080515T160000Z
DTSTAMP:20080506T105808Z
DTSTART:20080515T140000Z
LAST-MODIFIED:20080506T105808Z
LOCATION:113 vasco boulevard
ORGANIZER;CN="Mr M":mailto:XXXXXXX@bdsolutions.co.za
PRIORITY:5
SEQUENCE:0
SUMMARY;LANGUAGE=en-za:Meeting with marketing company
TRANSP:OPAQUE
UID:040000008200E00074C5B7101A82E00800000000E007C9D478AFC801000000000000000
	0100000001D3FEA0BE8947D4090BF51F4672A1079
X-ALT-DESC;FMTTYPE=text/html:<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//E
	N">\n<HTML>\n<HEAD>\n<META NAME="Generator" CONTENT="MS Exchange Server ve
	rsion 08.00.0681.000">\n<TITLE></TITLE>\n</HEAD>\n<BODY>\n<!-- Converted f
	rom text/rtf format -->\n\n<P DIR=LTR><SPAN LANG="en-za"><FONT FACE="Calib
	ri">When: 15 May 2008 04:00 PM-06:00 PM (GMT+02:00) Harare\, Pretoria.</FO
	NT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-za"><FONT FACE="Calibri">Where
	: office</FONT></SPAN></P>\n\n<P DIR=LTR><SPAN LANG="en-za"><
	FONT FACE="Calibri">*~*~*~*~*~*~*~*~*~*</FONT></SPAN></P>\n\n<P DIR=LTR><S
	PAN LANG="en-za"></SPAN></P>\n\n</BODY>\n</HTML>
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MS-OLK-ALLOWEXTERNCHECK:TRUE
X-MS-OLK-AUTOSTARTCHECK:FALSE
X-MS-OLK-CONFTYPE:0
X-MS-OLK-SENDER;CN="Mr M":mailto:XXXXXX@bdsolutions.co.za
BEGIN:VALARM
TRIGGER:-PT15M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR
I can imagine this is the delay when the itip bar looks up whether the item is already part of some of your calendars. We could use a throbber to notify progress.

Marcel, just to make sure: you aren't subscribed to network calendars?

I was also assuming that the processor usage was for this lookup, but the big delay seems to have something to do with the network as disconnecting the network causes a big speed increase. The delay is practically gone.

I am only subscribed to a Google calendar but that is switched off. No other network calendars.
(In reply to comment #2)
> I am only subscribed to a Google calendar but that is switched off. No other
> network calendars.
Visibility is irrelevant, *all* calendars are taken into account, thus I suspect this causing your delay. If you remove your gdata account, everything's fast? Anyway, IMO a throbber worth considering.

I can confirm the delay; it's unfortunate.
Status: UNCONFIRMED → NEW
Ever confirmed: true
You are right. Removing the Google calendar did the trick.

Although I still find it strange that this specific event takes 5 seconds to
show the buttons, while other show after only a slight delay. What is so
special about this event?
Each calendar needs to be queried for the event, which might take a while. In the Google case its even more tricky, since there is no way to get a single item with all exceptions without getting all items. Therefore it takes a bit longer on a Google Calendar.
I think all we can do hereis to show a throbber. Morphing summary to reflect.
Summary: Delay in appearance of Accept / Decline buttons → Show a throbber while waiting for imip bar to load getItem results (delay,buttons)
Where can I find the implementation of Itip response buttons window? Is it done inside OnMessageLoaded? Or inside the mimeconverter interface? I'm thinking of adding the throbber before the buttons load.
Its a mix between calItipUtils.jsm, and imip-bar.js. The parts you mention are too far down, we've abstracted that a bit. There is code that figures out which buttons to display, then it starts the calItipItemFinder, which takes a while, and then the buttons are shown.

You need to show the throbber when the item finder is running. There is also an imip-bar.xul that you can use to create the UI looks. I'd suggest hiding it behind a class and using CSS rules to display or not display the throbber.
Attached patch throbber.diff (obsolete) — — Splinter Review 
Here is a patch for the bug. There is a problem, It doesn't load the element via the anonid attribute. May be at the xml I have missed something. Once it could be loaded, all others should be fine.
Attachment #8408292 - Flags: review?(philipp)
Comment on attachment 8408292 [details] [diff] [review]
throbber.diff

Review of attachment 8408292 [details] [diff] [review]:
-----------------------------------------------------------------

::: calendar/lightning/content/imip-bar.js
@@ +126,5 @@
>              ltnImipBar.foundItems = foundItems;
>          }
>  		
> +		
> +	let imipThrobble = document.getAnonymousElementByAttribute(this, "anonid", "loading-throbber");

document.getAnonymousElementByAttribute only works within the binding, the first argument you are passing is the binding object. The lines are correct, but they should likely be in a different file.

To do this right you should probably instead show/hide the element with CSS, controlled by an attribute on the binding element.

Otherwise you are breaking the encapsulation and controlling logic of the binding from the outside. A binding should be considered something that can be re-usable. If you controll its behavior from the outside, then you'd have to use the same code everywhere and this is error prone and a maintenance nightmare.
Attachment #8408292 - Flags: review?(philipp) → review-
Assignee: nobody → malinthak2
Status: NEW → ASSIGNED
Attached patch bug-432774-throbber-added — — Splinter Review 

        Attachment #8408292 -
        Attachment is obsolete: true

        Attachment #8411744 -
        Flags: review?(philipp)

    
    

    
  
Comment on attachment 8411744 [details] [diff] [review]
bug-432774-throbber-added

Review of attachment 8411744 [details] [diff] [review]:
-----------------------------------------------------------------

Good job on getting the XBL binding to work, unfortunately we are not quite there yet. I am sorry if I was unclear.

I don't think it makes sense to create a whole new binding just for the throbber. I had meant to put the throbber image in to the lightning-notification-bar binding as a <xul:image>, being the last element in the binding's content. 

Then, instead of explicitly showing/hiding the image in imip-bar.js, instead set an attribute on the bar, i.e document.getElementById("imip-bar").setAttribute("loading", "true") and remove it later on where you previously used hideElement.

Then, in the xbl binding for lightning-notification-bar, use xbl:inherits="loading" as an attribute on the image and give it a class for later. This will let the image inherit the "loading" attribute of the binding itself.

Finally, you can add CSS to lightning-widgets.css to hide/show the image based on the loading attribute, i.e .lightning-notification-bar-image:not([loading]) { display: none; }

Does this make sense? Feel free to ping me on IRC if you have questions.

        Attachment #8411744 -
        Flags: review?(philipp) → review-
Assignee: malinthak2 → nobody
Status: ASSIGNED → NEW
OS: Windows XP → All
Hardware: x86 → All

    
  
Severity: normal → S3

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: