Closed
Bug 1513551
Opened 6 years ago
Closed 5 years ago
Developer Tools - chrome://messender/content/messenger.xul - (Not Responding)
Categories
(Thunderbird :: Untriaged, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: richard.leger, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0
Steps to reproduce:
Open Thunderbird 64.0b3 (32-bit) with -p -console options, use the debugger to debug performance issue with one network calendar (CalDav) - new profile, no email setup, one calendar setup only, NOT logging in to calendar at startup. Open DevTools window, double click on calendar to open properties (sometime TB seems not responding and it takes a long time for the Calendar Properties window to appear), enable calendar, press OK, enter and send credentials to login to calendar... and start debugging... at first everything seems ok... though sometime to time there are some UI lags (unresponsive but no mention of it)... use the debuger...
Actual results:
Regularly become unresponsive for a while with the mention "- (Not Responding)" appearing in the titel bar so it looks like this:
"Developer Tools - chrome://messender/content/messenger.xul - (Not Responding)" if you wait, it comes back most of the time but not always... situation seems to get worth over time...
That happens in various ways, when going through break points, trying to open .js file (mention Loading... appears for a long time prior data from file is shown on screen), close open file tabs in the Debugger, missing Debugger view, scroll down within a Performance recorded result or trying to switch to the JS Frame Chart tab, in Network when trying when going into the Response tab of a network request... it takes a long time to show the response (raw syntax)... and another long time to format it (colored syntax)... at sometime an alert about unresponsive script shows up...
And when it start to become unresponsive it seems to degrade over time even more...
Sometime it come to the point where only possibility is to close the DevTools window as no other user interaction are possible.
Expected results:
The DevTools window shall keep responding at all time...
Reporter | ||
Comment 1•6 years ago
|
||
I have also noticed it randomly when no even connecting to the calendar at all (disabled at all time) but trying to access its properties (via right click > properties or double click on calendar)... long delay for calendar properties window to appear... (especially the first time after TB startup... but cannot always reproduce the issue... though when it happened it may have been linked to the NSFrameConstructor processing taking long time to complete... as per performance record I had at the time but that I have lost unfortunately.
Lot of of CC Graph Reduction appears but that seems to be the case for most of TB processing...
Comment 2•6 years ago
|
||
Do you also see it with 65?
see https://archive.mozilla.org/pub/thunderbird/candidates/65.0b1-candidates/build5/win32/en-US/
> Lot of of CC Graph Reduction appears but that seems to be the case for most of TB processing...
Yes, I think that is normal.
Flags: needinfo?(richard.leger)
Reporter | ||
Comment 3•6 years ago
|
||
I have just updated to TB Version 65.0b1 (32-bit) so I will test again and report back shortly.
(In reply to Richard Leger from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0)
> Gecko/20100101 Firefox/63.0
>
> in Network when trying when going into the
> Response tab of a network request... it takes a long time to show the
> response (raw syntax)... and another long time to format it (colored
> syntax)... at sometime an alert about unresponsive script shows up...
FYI, about the Network issue observed as described above, I have created a separate Bug 1515123 as it may be separate root cause from issue described in this bug.
Though they might both be linked to performance issues in separate part of TB.
Reporter | ||
Comment 4•6 years ago
|
||
Still observed in TB Version 66.0b1 (32-bit) as per comment Bug 1515123 Comment 11
Flags: needinfo?(richard.leger)
Comment 5•5 years ago
|
||
Aceman, and Geoff, you use devtools a lot? Can you reproduce?
Flags: needinfo?(acelists)
I only use the devtools inspector and I think I remember some hangs in the past, but can't remember them recently.
Does this only happen when inspecting the calendar tab?
Flags: needinfo?(acelists)
Reporter | ||
Comment 7•5 years ago
|
||
I haven't noticed this issue in more recent version of TB so far... 70.x and later... so it may well have been fixed "itself"...
I have only tested and observed issue as per described originally... I could not say if it affected calendar tab only or else as well...
Calendar is quite data and network consuming so it may well be linked to large data set being parsed possibly or else...
Comment 8•5 years ago
|
||
Do you also see this issue when using versoin 68?
Whiteboard: [closeme 2020-01-04
Updated•5 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
Whiteboard: [closeme 2020-01-04
You need to log in
before you can comment on or make changes to this bug.
Description
•