Bugzilla

FYI, this issue is affecting 78.x and 80.0b5 basically still takes 10mn to load my 4000 items network calendar calDAV.

My suspicion would be issue surrounding the resource:///modules/caldav/CalDavRequestHandlers.jsm > characters (aValue) {...} function - parsing of the XML response...

From my recent testing and troubleshooting I have noticed the following during the async caldav multiget requests:
- TB is going into a "Not Responding" state **during the parsing by TB of a network response**, in DevTools > Network I can see:
-- The request starts (the response from server arrive quickly as seen in Task Manager)
-- TB become "Not Responding" for a while
-- TB resume normally the status code 207 appears in front of the request
-- The next request starts and the same issue occurs again

The "Not Responding" delay seems to become more and more prominent over time and really start to freeze TB at about the 20th requests (out of ~50 in total) then each request takes ages!

One may think that it is a network/server issue, but it is not because:
- The response time as indicated in DevTools is very short (also confirmed via Task Manager > Performance > Wifi graph) - and does not match the "Not Responding" delay
- The server logs also confirm the response is send back in due time - no delay server side...

I also noticed putting a breakpoint on the characters function that:
- Delay occurs at some point between two pauses on that breakpoint
- For one event item the function characters (aValue) {...} can be triggered 10,20 or more time as the aValue does not correspond to the overall item calendar caldata but only chuck of it e.g:

aValue in characters function can have the following values:

     "\n" at iteration 1
     "\n" at iteration 2, 
     "BEGIN:VCALENDAR" at iteration 3
     "\n" at iteration 4
     "PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN" at iteration 5
     "\n" at iteration 6 
     "VERSION:2.0" at iteration 7 
     "\n" at iteration 8 ,
     etc... 

For an event like:

    BEGIN:VCALENDAR
    PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
    VERSION:2.0
    (...)

After a high number of iteration over the item calendar data, the varialbe this.currentResponse[this.tag] ends up with a value like:
this.currentResponse["caldata"] = "\n\nBEGIN:VCALENDAR\nPRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN\nVERSION:2.0\n etc..."

An this is just for one items... it does it again for each calendar item... with sometime the value of aValue being just "<" or ">"... surely there must be a better to parse calendar data from an event item in **one** go... 

**Why the calendar data is parsed in chunked and not all at once when grasping it from the response?**

My suspicion may be **issue related to the SAX xml parser** currently in use which seems deprecated and non longer usable in Firefox (according to: https://developer.mozilla.org/en-US/docs/Archive/SAX)

I tend to convert email to Evant or Tasks a lot as well as having html data into the main body content of event/task items so maybe could that code chock the SAX xml parser somehow at some point... unless it may be a character encoding issue... or too much iteration over something... or the javascipt engine not liking processing from the SAX parser?

Also noted, each iteration to the *characters" function trigger calls **each time** it is run to the this.calendar.verboseLogging() function which run a comparison prior returning a value... that seems to me as an expensive and UN-necessary computation.

FYI, this issue is affecting 78.x and 80.0b5 basically still takes 10mn to load my 4000 items network calendar calDAV.

My suspicion would be issue surrounding the resource:///modules/caldav/CalDavRequestHandlers.jsm > characters (aValue) {...} function - parsing of the XML response...

From my recent testing and troubleshooting I have noticed the following during the async caldav multiget requests:
- TB is going into a "Not Responding" state **during the parsing by TB of a network response**, in DevTools > Network I can see:
-- The request starts (the response from server arrive quickly as seen in Task Manager)
-- TB become "Not Responding" for a while
-- TB resume normally the status code 207 appears in front of the request
-- The next request starts and the same issue occurs again

The "Not Responding" delay seems to become more and more prominent over time and really start to freeze TB at about the 20th requests (out of ~50 in total) then each request takes ages!

One may think that it is a network/server issue, but it is not because:
- The response time as indicated in DevTools is very short (also confirmed via Task Manager > Performance > Wifi graph) - and does not match the "Not Responding" delay
- The server logs also confirm the response is send back in due time - no delay server side...

I also noticed putting a breakpoint on the characters function that:
- Delay occurs at some point between two pauses on that breakpoint
- For one event item the function characters (aValue) {...} can be triggered 10,20 or more time as the aValue does not correspond to the overall item calendar caldata but only chuck of it e.g:

aValue in characters function can have the following values:

     "\n" at iteration 1
     "\n" at iteration 2, 
     "BEGIN:VCALENDAR" at iteration 3
     "\n" at iteration 4
     "PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN" at iteration 5
     "\n" at iteration 6 
     "VERSION:2.0" at iteration 7 
     "\n" at iteration 8 ,
     etc... 

For an event like:

    BEGIN:VCALENDAR
    PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
    VERSION:2.0
    (...)

After a high number of iteration over the item calendar data, the varialbe this.currentResponse[this.tag] ends up with a value like:
this.currentResponse["caldata"] = "\n\nBEGIN:VCALENDAR\nPRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN\nVERSION:2.0\n etc..."

An this is just for one items... it does it again for each calendar item... with sometime the value of aValue being just "<" or ">"... surely there must be a better to parse calendar data from an event item in **one** go... 

**Why the calendar data is parsed in chunked and not all at once when grasping it from the response?**

My suspicion may be **issue related to the SAX xml parser** currently in use which seems deprecated and non longer usable in Firefox (according to: https://developer.mozilla.org/en-US/docs/Archive/SAX)

I tend to convert email to Evant or Tasks a lot as well as having html data into the main body content of event/task items so maybe could that code chock the SAX xml parser somehow at some point... unless it may be a character encoding issue... or too much iteration over something... or the javascipt engine not liking processing from the SAX parser?

Also noted, each iteration to the *characters" function trigger calls **each time** it is run to the this.calendar.verboseLogging() function which run a comparison prior returning a value... that seems to me as an expensive and UN-necessary computation.
Why not to use just this.calendar.mVerboseLogging (which only need to be initialised upon calendar object creation) or even better don't use the character function to log the XMLlog data, either just get it from the response itself direction which is arleady in html format or copy the data store in this.currentResponse after computation has completed for the event item. Don't think there is any need to concatenate twice the same value into two location via the characters function... which should solely be used to grap the caldata the event item in an iCal format...

Looking at those may also be a good start to fix perf issue with CalDAV.

FYI, this issue is affecting 78.x and 80.0b5 basically still takes 10mn to load my 4000 items network calendar calDAV.

My suspicion would also be issues surrounding the resource:///modules/caldav/CalDavRequestHandlers.jsm > characters (aValue) {...} function - parsing of the XML response...

From my recent testing and troubleshooting I have noticed the following during the async caldav multiget requests:
- TB is going into a "Not Responding" state **during the parsing by TB of a network response**, in DevTools > Network I can see:
-- The request starts (the response from server arrive quickly as seen in Task Manager)
-- TB become "Not Responding" for a while
-- TB resume normally the status code 207 appears in front of the request
-- The next request starts and the same issue occurs again

The "Not Responding" delay seems to become more and more prominent over time and really start to freeze TB at about the 20th requests (out of ~50 in total) then each request takes ages!

One may think that it is a network/server issue, but it is not because:
- The response time as indicated in DevTools is very short (also confirmed via Task Manager > Performance > Wifi graph) - and does not match the "Not Responding" delay
- The server logs also confirm the response is send back in due time - no delay server side...

I also noticed putting a breakpoint on the characters function that:
- Delay occurs at some point between two pauses on that breakpoint
- For one event item the function characters (aValue) {...} can be triggered 10,20 or more time as the aValue does not correspond to the overall item calendar caldata but only chuck of it e.g:

aValue in characters function can have the following values:

     "\n" at iteration 1
     "\n" at iteration 2, 
     "BEGIN:VCALENDAR" at iteration 3
     "\n" at iteration 4
     "PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN" at iteration 5
     "\n" at iteration 6 
     "VERSION:2.0" at iteration 7 
     "\n" at iteration 8 ,
     etc... 

For an event like:

    BEGIN:VCALENDAR
    PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
    VERSION:2.0
    (...)

After a high number of iteration over the item calendar data, the varialbe this.currentResponse[this.tag] ends up with a value like:
this.currentResponse["caldata"] = "\n\nBEGIN:VCALENDAR\nPRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN\nVERSION:2.0\n etc..."

An this is just for one items... it does it again for each calendar item... with sometime the value of aValue being just "<" or ">"... surely there must be a better way to parse calendar data from an event item in **one** go... 

**Why the calendar data is parsed in chunked and not all at once when grasping it from the response?**

My suspicion may be **issue related to the SAX xml parser** currently in use which seems deprecated and non longer usable in Firefox (according to: https://developer.mozilla.org/en-US/docs/Archive/SAX)

I tend to convert email to Evant or Tasks a lot as well as having html data into the main body content of event/task items so maybe could that code chock the SAX xml parser somehow at some point... unless it may be a character encoding issue... or too much iteration over something... or the javascipt engine not liking processing from the SAX parser?

Alternatively it could be that the parsed object is then passed over to an observer to refresh data in a view and that the view chock on the data?

Also noted, each iteration to the *characters" function trigger calls **each time** it is run to the this.calendar.verboseLogging() function which run a comparison prior returning a value... that seems to me as an expensive and UN-necessary computation.
Why not to use just this.calendar.mVerboseLogging (which only need to be initialised upon calendar object creation) or even better don't use the character function to log the XMLlog data, either just get it from the response itself direction which is already in html format or copy the data store in this.currentResponse after computation has completed for the event item. Don't think there is any need to concatenate twice the same value into two location via the characters function... which should solely be used to grap the caldata the event item in an iCal format...

Looking at those may also be a good start to fix perf issue with CalDAV.

FYI, this issue is affecting 78.x and 80.0b5 basically still takes 10mn to load my 4000 items network calendar calDAV.

My suspicion would also be issues surrounding the resource:///modules/caldav/CalDavRequestHandlers.jsm > characters (aValue) {...} function - parsing of the XML response...

From my recent testing and troubleshooting I have noticed the following during the async caldav multiget requests:
- TB is going into a "Not Responding" state **during the parsing by TB of a network response**, in DevTools > Network I can see:
-- The request starts (the response from server arrive quickly as seen in Task Manager)
-- TB become "Not Responding" for a while
-- TB resume normally the status code 207 appears in front of the request
-- The next request starts and the same issue occurs again

The "Not Responding" delay seems to become more and more prominent over time and really start to freeze TB at about the 20th requests (out of ~50 in total) then each request takes ages!

One may think that it is a network/server issue, but it is not because:
- The response time as indicated in DevTools is very short (also confirmed via Task Manager > Performance > Wifi graph) - and does not match the "Not Responding" delay
- The server logs also confirm the response is send back in due time - no delay server side...

I also noticed putting a breakpoint on the characters function that:
- Delay occurs at some point between two pauses on that breakpoint
- For one event item the function characters (aValue) {...} can be triggered 10,20 or more time as the aValue does not correspond to the overall item calendar caldata but only chuck of it e.g:

aValue in characters function can have the following values:

     "\n" at iteration 1
     "\n" at iteration 2, 
     "BEGIN:VCALENDAR" at iteration 3
     "\n" at iteration 4
     "PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN" at iteration 5
     "\n" at iteration 6 
     "VERSION:2.0" at iteration 7 
     "\n" at iteration 8 ,
     etc... 

For an event like:

    BEGIN:VCALENDAR
    PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
    VERSION:2.0
    (...)

After a high number of iteration over the item calendar data, the varialbe this.currentResponse[this.tag] ends up with a value like:
this.currentResponse["caldata"] = "\n\nBEGIN:VCALENDAR\nPRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN\nVERSION:2.0\n etc..."

An this is just for one items... it does it again for each calendar item... with sometime the value of aValue being just "<" or ">"... surely there must be a better way to parse calendar data from an event item in **one** go... 

**Why the calendar item data is parsed in chunked and not all at once when grasping it from the XML response?**

My suspicion may be **issue related to the SAX xml parser** currently in use which seems deprecated and non longer usable in Firefox (according to: https://developer.mozilla.org/en-US/docs/Archive/SAX)

I tend to convert email to Evant or Tasks a lot as well as having html data into the main body content of event/task items so maybe could that code chock the SAX xml parser somehow at some point... unless it may be a character encoding issue... or too much iteration over something... or the javascipt engine not liking processing from the SAX parser?

Alternatively it could be that the parsed object is then passed over to an observer to refresh data in a view and that the view chock on the data?

Also noted, each iteration to the *characters" function trigger calls **each time** it is run to the this.calendar.verboseLogging() function which run a comparison prior returning a value... that seems to me as an expensive and UN-necessary computation.
Why not to use just this.calendar.mVerboseLogging (which only need to be initialised upon calendar object creation) or even better don't use the character function to log the XMLlog data, either just get it from the response itself direction which is already in html format or copy the data store in this.currentResponse after computation has completed for the event item. Don't think there is any need to concatenate twice the same value into two location via the characters function... which should solely be used to grap the caldata the event item in an iCal format...

Looking at those may also be a good start to fix perf issue with CalDAV.

FYI, this issue is affecting 78.x and 80.0b5 basically still takes 10mn to load my 4000 items network calendar calDAV.

My suspicion would also be issues surrounding the resource:///modules/caldav/CalDavRequestHandlers.jsm > characters (aValue) {...} function - parsing of the XML response...

From my recent testing and troubleshooting I have noticed the following during the async caldav multiget requests:
- TB is going into a "Not Responding" state **during the parsing by TB of a network response**, in DevTools > Network I can see:
-- The request starts (the response from server arrive quickly as seen in Task Manager)
-- TB become "Not Responding" for a while
-- TB resume normally the status code 207 appears in front of the request
-- The next request starts and the same issue occurs again

The "Not Responding" delay seems to become more and more prominent over time and really start to freeze TB at about the 20th requests (out of ~50 in total) then each request takes ages!

One may think that it is a network/server issue, but it is not because:
- The response time as indicated in DevTools is very short (also confirmed via Task Manager > Performance > Wifi graph) - and does not match the "Not Responding" delay
- The server logs also confirm the response is send back in due time - no delay server side...

I also noticed putting a breakpoint on the characters function that:
- Delay occurs at some point between two pauses on that breakpoint
- For one event item the function characters (aValue) {...} can be triggered 10,20 or more time as the aValue does not correspond to the overall item calendar caldata but only chuck of it e.g:

aValue in characters function can have the following values:

     "\n" at iteration 1
     "\n" at iteration 2, 
     "BEGIN:VCALENDAR" at iteration 3
     "\n" at iteration 4
     "PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN" at iteration 5
     "\n" at iteration 6 
     "VERSION:2.0" at iteration 7 
     "\n" at iteration 8 ,
     etc... 

For an event like:

    BEGIN:VCALENDAR
    PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
    VERSION:2.0
    (...)

After a high number of iteration over the item calendar data, the varialbe this.currentResponse[this.tag] ends up with a value like:
this.currentResponse["caldata"] = "\n\nBEGIN:VCALENDAR\nPRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN\nVERSION:2.0\n etc..."

An this is just for one items... it does it again for each calendar item... with sometime the value of aValue being just "<" or ">"... surely there must be a better way to parse calendar data from an event item in **one** go... 

**Why the calendar item data is parsed in chunked and not all at once when grasping it from the XML response?**

My suspicion may be **issue related to the SAX xml parser** currently in use which seems deprecated and non longer usable in Firefox (according to: https://developer.mozilla.org/en-US/docs/Archive/SAX)

I tend to convert email to Event or Task a lot causing item main body content of event/task to contain html (aka xml) data, so maybe could that code choke the SAX xml parser somehow at some point... unless it may be a character encoding issue... or too much iteration over something... or the javascipt engine not liking processing from the SAX parser?

Due to the async processing of such request, it make it impossible to step in the code to identify where exactly the slow down not responsiveness starts to occur... which could also indicate a Core issue...

Alternatively it could be that the parsed object is then passed over to an observer to refresh data in a view and that the view choke on the data?

Also noted, each iteration to the *characters" function trigger calls **each time** it is run to the this.calendar.verboseLogging() function which run a comparison prior returning a value... that seems to me as an expensive and UN-necessary repetitive computation.
Why not to use just this.calendar.mVerboseLogging variable instead which only need to be initialised once upon calendar object creation or even better don't use the character function to log the XMLlog data, either just get it from the response itself direction which is already in html format or copy the data store in this.currentResponse after computation has completed for the event item. Don't think there is any need to concatenate twice the same value into two location via the characters function... which should solely be used to grap the caldata the event item in an iCal format...

Looking at those may also be a good start to fix perf issue with CalDAV.

FYI, this issue is affecting 78.x and 80.0b5 basically still takes 10mn to load my 4000 items network calendar calDAV.

My suspicion would also be issues surrounding the resource:///modules/caldav/CalDavRequestHandlers.jsm > characters (aValue) {...} function - parsing of the XML response...

From my recent testing and troubleshooting I have noticed the following during the async caldav multiget requests:
- TB is going into a "Not Responding" state **during the parsing by TB of a network response**, in DevTools > Network I can see:
-- The request starts (the response from server arrive quickly as seen in Task Manager)
-- TB become "Not Responding" for a while
-- TB resume normally the status code 207 appears in front of the request
-- The next request starts and the same issue occurs again

The "Not Responding" delay seems to become more and more prominent over time and really start to freeze TB at about the 20th requests (out of ~50 in total) then each request takes ages!

One may think that it is a network/server issue, but it is not because:
- The response time as indicated in DevTools is very short (also confirmed via Task Manager > Performance > Wifi graph) - and does not match the "Not Responding" delay
- The server logs also confirm the response is send back in due time - no delay server side...

I also noticed putting a breakpoint on the characters function that:
- Delay occurs at some point between two pauses on that breakpoint
- For one event item the function characters (aValue) {...} can be triggered 10,20 or more time as the aValue does not correspond to the overall item calendar caldata but only chunck of it e.g:

aValue in characters function can have the following values:

     "\n" at iteration 1
     "\n" at iteration 2, 
     "BEGIN:VCALENDAR" at iteration 3
     "\n" at iteration 4
     "PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN" at iteration 5
     "\n" at iteration 6 
     "VERSION:2.0" at iteration 7 
     "\n" at iteration 8 ,
     etc... 

For an event like:

    BEGIN:VCALENDAR
    PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
    VERSION:2.0
    (...)

After a high number of iteration over the item calendar data, the varialbe this.currentResponse[this.tag] ends up with a value like:
this.currentResponse["caldata"] = "\n\nBEGIN:VCALENDAR\nPRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN\nVERSION:2.0\n etc..."

An this is just for one items... it does it again for each calendar item... with sometime the value of aValue being just "<" or ">"... surely there must be a better way to parse calendar data from an event item in **one** go... 

**Why the calendar item data is parsed in chunked and not all at once when grasping it from the XML response?**

My suspicion may be **issue related to the SAX xml parser** currently in use which seems deprecated and non longer usable in Firefox (according to: https://developer.mozilla.org/en-US/docs/Archive/SAX)

I tend to convert email to Event or Task a lot causing item main body content of event/task to contain html (aka xml) data, so maybe could that code choke the SAX xml parser somehow at some point... unless it may be a character encoding issue... or too much iteration over something... or the javascipt engine not liking processing from the SAX parser?

Due to the async processing of such request, it make it impossible to step in the code to identify where exactly the slow down not responsiveness starts to occur... which could also indicate a Core issue...

Alternatively it could be that the parsed object is then passed over to an observer to refresh data in a view and that the view choke on the data?

Also noted, each iteration to the *characters" function trigger calls **each time** it is run to the this.calendar.verboseLogging() function which run a comparison prior returning a value... that seems to me as an expensive and UN-necessary repetitive computation.
Why not to use just this.calendar.mVerboseLogging variable instead which only need to be initialised once upon calendar object creation or even better don't use the character function to log the XMLlog data, either just get it from the response itself direction which is already in html format or copy the data store in this.currentResponse after computation has completed for the event item. Don't think there is any need to concatenate twice the same value into two location via the characters function... which should solely be used to grap the caldata the event item in an iCal format...

Looking at those may also be a good start to fix perf issue with CalDAV.

FYI, this issue is affecting 78.x and 80.0b5 basically still takes 10mn to load my 4000 items network calendar calDAV.

My suspicion would also be issues surrounding the resource:///modules/caldav/CalDavRequestHandlers.jsm > characters (aValue) {...} function - parsing of the XML response...

From my recent testing and troubleshooting I have noticed the following during the async caldav multiget requests:
- TB is going into a "Not Responding" state **during the parsing by TB of a network response**, in DevTools > Network I can see:
-- The request starts (the response from server arrive quickly as seen in Task Manager)
-- TB become "Not Responding" for a while
-- TB resume normally the status code 207 appears in front of the request
-- The next request starts and the same issue occurs again

The "Not Responding" delay seems to become more and more prominent over time and really start to freeze TB at about the 20th requests (out of ~50 in total) then each request takes ages!

One may think that it is a network/server issue, but it is not because:
- The response time as indicated in DevTools is very short (also confirmed via Task Manager > Performance > Wifi graph) - and does not match the "Not Responding" delay
- The server logs also confirm the response is send back in due time - no delay server side...

I also noticed putting a breakpoint on the characters function that:
- Delay occurs at some point between two pauses on that breakpoint
- For one event item the function characters (aValue) {...} can be triggered 10,20 or more time as the aValue does not correspond to the overall item calendar caldata but only chunck of it e.g:

aValue in characters function can have the following values:

     "\n" at iteration 1
     "\n" at iteration 2, 
     "BEGIN:VCALENDAR" at iteration 3
     "\n" at iteration 4
     "PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN" at iteration 5
     "\n" at iteration 6 
     "VERSION:2.0" at iteration 7 
     "\n" at iteration 8 ,
     etc... 

For an event like:

    BEGIN:VCALENDAR
    PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
    VERSION:2.0
    (...)

After a high number of iteration over the item calendar data, the varialbe this.currentResponse[this.tag] ends up with a value like:
this.currentResponse["caldata"] = "\n\nBEGIN:VCALENDAR\nPRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN\nVERSION:2.0\n etc..."

An this is just for one items... it does it again for each calendar item... with sometime the value of aValue being just "<" or ">"... surely there must be a better way to parse calendar data from an event item in **one** go... 

**Why the calendar item data is parsed in chunked and not all at once when grasping it from the XML response?**

My suspicion may be **issue related to the SAX xml parser** currently in use which seems deprecated and non longer usable in Firefox (according to: https://developer.mozilla.org/en-US/docs/Archive/SAX)

I tend to convert email to Event or Task a lot causing item main body content to contain html (aka xml) data, so maybe could that code choke the SAX xml parser somehow at some point... unless it may be a character encoding issue... or too much iteration over something... or the javascipt engine not liking processing from the SAX parser?

Due to the async processing of such request, it make it impossible to step in the code to identify where exactly the slow down not responsiveness starts to occur... which could also indicate a Core issue...

Alternatively it could be that the parsed object is then passed over to an observer to refresh data in a view and that the view choke on the data?

Also noted, each iteration to the *characters" function trigger calls **each time** it is run to the this.calendar.verboseLogging() function which run a comparison prior returning a value... that seems to me as an expensive and UN-necessary repetitive computation.
Why not to use just this.calendar.mVerboseLogging variable instead which only need to be initialised once upon calendar object creation or even better don't use the character function to log the XMLlog data, either just get it from the response itself direction which is already in html format or copy the data store in this.currentResponse after computation has completed for the event item. Don't think there is any need to concatenate twice the same value into two location via the characters function... which should solely be used to grap the caldata the event item in an iCal format...

Looking at those may also be a good start to fix perf issue with CalDAV.

FYI, this issue is affecting 78.x and 80.0b5 basically still takes 10mn to load my 4000 items network calendar calDAV.

My suspicion would also be issues surrounding the resource:///modules/caldav/CalDavRequestHandlers.jsm > characters (aValue) {...} function - parsing of the XML response...

From my recent testing and troubleshooting I have noticed the following during the async caldav multiget requests:
- TB is going into a "Not Responding" state **during the parsing by TB of a network response**, in DevTools > Network I can see:
-- The request starts (the response from server arrive quickly as seen in Task Manager)
-- TB become "Not Responding" for a while
-- TB resume normally the status code 207 appears in front of the request
-- The next request starts and the same issue occurs again

The "Not Responding" delay seems to become more and more prominent over time and really start to freeze TB at about the 20th requests (out of ~50 in total) then each request takes ages!

One may think that it is a network/server issue, but it is not because:
- The response time as indicated in DevTools is very short (also confirmed via Task Manager > Performance > Wifi graph) - and does not match the "Not Responding" delay
- The server logs also confirm the response is send back in due time - no delay server side...

I also noticed putting a breakpoint on the characters function that:
- Delay occurs at some point between two pauses on that breakpoint
- For one event item the function characters (aValue) {...} can be triggered 10,20 or more time as the aValue does not correspond to the overall item calendar caldata but only chunck of it e.g:

aValue in characters function can have the following values:

     "\n" at iteration 1
     "\n" at iteration 2, 
     "BEGIN:VCALENDAR" at iteration 3
     "\n" at iteration 4
     "PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN" at iteration 5
     "\n" at iteration 6 
     "VERSION:2.0" at iteration 7 
     "\n" at iteration 8 ,
     etc... 

For an event like:

    BEGIN:VCALENDAR
    PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
    VERSION:2.0
    (...)

After a high number of iteration over the item calendar data, the varialbe this.currentResponse[this.tag] ends up with a value like:
this.currentResponse["caldata"] = "\n\nBEGIN:VCALENDAR\nPRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN\nVERSION:2.0\n etc..."

An this is just for one items... it does it again for each calendar item... with sometime the value of aValue being just "<" or ">"... surely there must be a better way to parse calendar data from an event item in **one** go... 

**Why the calendar item data is parsed in chunks and not all at once when grasping it from the XML response?**

My suspicion may be **issue related to the SAX xml parser** currently in use which seems deprecated and non longer usable in Firefox (according to: https://developer.mozilla.org/en-US/docs/Archive/SAX)

I tend to convert email to Event or Task a lot causing item main body content to contain html (aka xml) data, so maybe could that code choke the SAX xml parser somehow at some point... unless it may be a character encoding issue... or too much iteration over something... or the javascipt engine not liking processing from the SAX parser?

Due to the async processing of such request, it make it impossible to step in the code to identify where exactly the slow down not responsiveness starts to occur... which could also indicate a Core issue...

Alternatively it could be that the parsed object is then passed over to an observer to refresh data in a view and that the view choke on the data?

Also noted, each iteration to the *characters" function trigger calls **each time** it is run to the this.calendar.verboseLogging() function which run a comparison prior returning a value... that seems to me as an expensive and UN-necessary repetitive computation.
Why not to use just this.calendar.mVerboseLogging variable instead which only need to be initialised once upon calendar object creation or even better don't use the character function to log the XMLlog data, either just get it from the response itself direction which is already in html format or copy the data store in this.currentResponse after computation has completed for the event item. Don't think there is any need to concatenate twice the same value into two location via the characters function... which should solely be used to grap the caldata the event item in an iCal format...

Looking at those may also be a good start to fix perf issue with CalDAV.