Steps to reproduce: 1. Set up thunderbird so that you have at least one mail folder with many messages. In my test, I put over 17,000 messages in my Trash folder. 2. Quit thunderbird. 3. Download the attached statechanged.py accessible event listener. 4. In a terminal, do the following: $ gsettings set org.gnome.desktop.interface toolkit-accessibility true $ NO_AT_BRIDGE=1 $ ./statechanged.py & $ ./path/to/thunderbird/being/tested 5. Give focus to the tree of mailboxes on the left. 6. Arrow from the top to the bottom, then back up to the top, then back to the bottom, then back to the top, .... Expected results: At no time would Thunderbird become unresponsive. Actual results: As you arrow past the mail folder with thousands of messages, Thunderbird becomes completely unresponsive and remains that way for multiple seconds. (> 5 on my i7-3770K CPU @ 3.50GHz; Orca users have reported it taking up to 15 seconds on their machines.) This bug is NOT present in nightlies ("Daily") from 29 Dec 2013 and earlier. This bug IS present beginning in the Daily from 30 December and persists in current builds.

Trev, would you mind to look pls? Is it tree items creation or destruction?

When Thunderbird is used with orca and such a lag happens it is no longer possible to interact with the main window. The workarounds which can return accessibility support back to normal include restarting orca or opening and closing some tool windows in thunderbird such as saved files, error console etc.

> $ gsettings set org.gnome.desktop.interface toolkit-accessibility true > $ NO_AT_BRIDGE=1 > $ ./statechanged.py & > $ ./path/to/thunderbird/being/tested > > 5. Give focus to the tree of mailboxes on the left. > > 6. Arrow from the top to the bottom, then back up to the top, then back to > the bottom, then back to the top, .... > > Expected results: At no time would Thunderbird become unresponsive. hrm, it certainly seems to hang, the biggest use of time appears to be doing ipc so maybe firing events. The only other a11y related thing taking up time is CC of accessibles, but that's only a few percent. > This bug is NOT present in nightlies ("Daily") from 29 Dec 2013 and earlier. > This bug IS present beginning in the Daily from 30 December and persists in > current builds. surely that date is wrong given dec 29 2013 is in the future

(In reply to Trevor Saunders (:tbsaunde) from comment #3) > surely that date is wrong given dec 29 2013 is in the future My bad. 29 Dec 2012 and earlier are fine. 30 Dec 2012 to present day are broken.

(In reply to Joanmarie Diggs from comment #4) > (In reply to Trevor Saunders (:tbsaunde) from comment #3) > > 29 Dec 2012 and earlier are fine. 30 Dec 2012 to present day are broken. Thanks for that. Only a couple mail checkins http://hg.mozilla.org/comm-central/pushloghtml?startdate=2012-12-29%2004:00:00&enddate=2012-12-30%2006:00:00 But huge list of firefox checkins http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-12-29%2004:00:00&enddate=2012-12-30%2006:00:00 No mail perf bugs since then are fixed https://bugzilla.mozilla.org/buglist.cgi?keywords=perf&keywords_type=allwords&f1=OP&o3=nowordssubstr&list_id=8184787&v3=bulk&resolution=FIXED&classification=Client%20Software&classification=Components&o2=anywordssubstr&f4=CP&chfieldto=Now&chfield=[Bug%20creation]&query_format=advanced&j1=OR&chfieldfrom=2012-12-30&f3=status_whiteboard&f2=short_desc&product=MailNews%20Core&product=Thunderbird And I don't see anything that matches in currently open perf bugs https://bugzilla.mozilla.org/buglist.cgi?keywords=perf&keywords_type=allwords&f1=OP&o3=nowordssubstr&list_id=8184785&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&v3=bulk&resolution=---&classification=Client%20Software&classification=Components&o2=anywordssubstr&f4=CP&chfieldto=Now&chfield=[Bug%20creation]&query_format=advanced&j1=OR&chfieldfrom=2012-12-30&f3=status_whiteboard&f2=short_desc&product=MailNews%20Core&product=Thunderbird Can you please check a nightly build, to see if the problem exists there? https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/

For me this is happening with oct 08 nightly. I haven't yet checked with more recent one.

(In reply to Wayne Mery (:wsmwk) from comment #5) > Can you please check a nightly build, to see if the problem exists there? Yes, the problem exists there. BTW, this is an accessibility-specific issue.

October 8 is good enough of a check. I don't see anything open core regression bugs https://bugzilla.mozilla.org/buglist.cgi?keywords=perf%2C%20regression%2C%20&keywords_type=allwords&f1=OP&o3=nowordssubstr&list_id=8184943&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&v3=bulk&resolution=---&classification=Client%20Software&classification=Components&o2=anywordssubstr&f4=CP&chfieldto=Now&chfield=[Bug%20creation]&query_format=advanced&j1=OR&chfieldfrom=2012-12-30&f3=status_whiteboard&f2=short_desc&product=Core either (although there could be a perf bug not marked as a regression) Also, importantly, I forgot to muse that I find it odd no one reported this in 9 months of Thunderbird development (since 2013-12-30), which would sadly indicate that we don't have any orca or other reader users using or testing alphas or betas.

yes this is looking like there are really no orca users testing betas or nightlies of thunderbird. I am considering starting doing this my-self because this issue somewhat slowed me down somewhat.

I don't have a technical proof that this is really causing this issue but the most visible a11y related change when upgrading from Thunderbird 17 to Thunderbird 24 is the fact that now the status bar is setup as a live region. Everything that's written there is dirrectly communicated to AT at least this how it looks like. I am getting spoken notifications for example: looking up hostname, connecting to a server, reading folder inbox etc. I don't know if this is normal but while inspecting orca debug output I can see a lot of text change events in there containing a lot of text from status bar. What I am not sure might be an issue is the fact that these events don't contain full status bar messages but instead these are split using some irregular logic I was unable to determine. Sometimes they are three, four, five characters long and sometimes these are corresponding with the messages displayed on the status bar. While opening a folder this status is being updated a lot giving progress as messages are loading. I don't know if this is something that may cause issues. I have already discusses this bit in the orca email list so most likelly it has nothing to do with this particular bug however It looks as this is verry difficult to identify and I got an impression I might at least post my speculation in order to try looking at this from another point of view. Greetings Peter

(In reply to Peter Vágner from comment #10) > I don't have a technical proof that this is really causing this issue but > the most visible a11y related change when upgrading from Thunderbird 17 to > Thunderbird 24 is the fact that now the status bar is setup as a live > region. Actually, it's not set up as a live region. But when the original live region support was added to Orca, the developer implementing the support found quite a few instances where functional live regions were not properly marked up via ARIA. So he added heuristic detection. Regardless, I very strongly suspect that this is a red herring: 1) We're not getting flooded by these events. 2) The events we do get are the same regardless of the number of messages in the folder. If you were so motivated (I am not), you could do what I did and try the nightlies one by one to find the exact day when the status bar changes were made. While this is an "accessibility-specific issue," I suspect the code change in question is not accessibility-specific. My guess is that something changed w.r.t. the tree itself. And it might not even be a big change in terms of lines of code. For instance, perhaps the model used to be disconnected from the tree widget when changing folders and now isn't disconnected from the tree. In this hypothetical case you'd have around 17,000 rows of messages times, say, six columns for a total of 102,000 accessible objects each of which might be saying something about their creation or destruction to the AT-SPI2 registry.

You are right I might have tried doing what you did in the first place instead of coming up with bizare theories. In the future once I will find a bug I will try doing that if there are not enough other usefull details. Still I think the info regarding status bar reporting might be important. With Thunderbird 17 status bar changes were not reported by Orca. Once again I apologise for taking your time and posting stuff you think is not appropriate. I appreciate what you are putting into this.

So, I looked at this some last week thunderbird itself doesn't seem to eat up that much CPU and of what it uses a11y doesn't do much the biggest chunk of time related to a11y stuff is cycle collection then some glib event dispatch stuff. So I suspect the issue is infact dispatching to many events, but I haven't yet looked at what events we fired before and what we fire after whatever changed. I looked at the pushlog and nothing a11y related jumped out at me as likely to be responsible, I suppose its vaguelly possible the xul:deck thing surkov landed is at fault but that seems pretty far fetched. I didn't see any changes to xul layout but I didn't look at non-a11y stuff that closely yet.

(In reply to Joanmarie Diggs from comment #11) > Regardless, I very > strongly suspect that this is a red herring: 1) We're not getting flooded by > these events. 2) The events we do get are the same regardless of the number > of messages in the folder. If you were so motivated (I am not), you could do > what I did and try the nightlies one by one to find the exact day when the > status bar changes were made. I have to apology again. I have originally miss-read your comment. I was under the impression you are about to say that I should have tested various builds even before I started tallking about this issue meaning I have wasted your time while you were investigating when the freeze started to occur. Now I started looking to what you've actually suggested so I will try to look for the build when the status bar reporting changed similar to the live region anouncements. I have loaded Dec 30 nightly (this one to be exact ( http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2012/12/2012-12-30-03-03-55-comm-central/thunderbird-20.0a1.en-US.linux-x86_64.tar.bz2 ) and I have noticed I am unable to navigate through the folder tree in this build. I am not sure I can describe it properly. While tabbing around I am getting anouncement it's a tree however when it is in focus arrowing does not cause any audible feetback from orca. I will try some more builds just in case this has something to do with my setup. Greetings Peter

Okay, I have started again with a fresh thunderbird profile and I can say that dec 29 2012 build does not cause a lag on my system and it also does not cause orca to automatically read statusbar changes similar how the live regions are being announced. Unfortunatelly 30 dec 2012 build causes the lag as Joanie has identified and also causes orca to report status bar changes. As I said before I am unable to judge whether these things contribute to each other however I am afraid this is not a coincidence. Can anyone please try to confirm this. I am afraid because while I was testing 30 dec build for the first time yesterday I was unable to navigate over the folder tree using the keyboard at all.

Please is there something I might be able to do? Thunderbird 24.0.1 is here with this issue present. Is some more testing needed?

So, I looked into this a little more, and it looks like the vast majority of the events being fired are parent-changed notifications (something like 10,000 of them). Those are only ifred when either getParentCB or refChildCB is called which are respectively the get parent and get child at "virtual functions". Internally we only call refChildCB once when firing children added events, but since I'm not seeing any of those following the parent changed events I suspect that's not what's calling get parent so much. The accessibles involved in the events are for messages, so I suspect for some reason orca is getting all the kids of the xul tree for messages, and the result of that is a whole bunch of events. Now I'm not sure this lazy event thing is great, but I suspect even if we fixed that this would still be kind of slow, so I find myself wondering why the full set of messages is being walked and if we can not do that. btw I can't get the 12/28/2012 or 12/29/2012 nightly builds to do anything useful.

Do I understand right that work hypothesis is some Thunderbird/Gecko change caused Orca to fetch all children and we need help from Orca developers? If so Trev can you request needinfo from Joanie? (btw, thanks for looking into this bug)

Note that in my opening report, I provided a listener. This bug happens without Orca.

After doing a bisect over the check-ins for the December 29, 2012 nightly, the commit causing the performance issue is the fix for bug 814836. I'll do further investigation to see what exactly is causing the problem in the commit.

It seems that the added nsAccessibilityService::DeckPanelSwitched triggers a DocAccessible::ContentInserted. This goes through all of the tree updating code for the entirety of the messages in the folder that we just switched to. The mass parent-changed notifications are coming from all the children firing show/hide events, calling getParentCB in the process in the ATK AccessibleWrap. This wasn't an issue prior to the change since we never triggered the full tree traversal. Removing it would cause issues with the original bug 814836, though, so I'm not sure how we'd want to proceed.

While I don't know the answer to "how we'd want to proceed," I'm curious as to whether or not this problem is unique to ATK/AT-SPI2 or if it is also present in IA2. If there's something specific to ATK/AT-SPI2 that is causing this and IA2 is free of this issue, maybe we can find a sane solution/compromise by working together (y'all + GNOME Accessibility). p.s. Thank you, thank you, thank you for taking this one on. :)

No worries, haha. With regards to IA2, this is not an issue when I tested with NVDA and current release Thunderbird on the same folder set - there was no noticeable slowdown when arrowing through. Wondering if Alex has any ideas, since he worked on the original xul:deck fix.

(In reply to Jonathan Wei [:jwei] from comment #21) > It seems that the added nsAccessibilityService::DeckPanelSwitched triggers a > DocAccessible::ContentInserted. This goes through all of the tree updating > code for the entirety of the messages in the folder that we just switched > to. The mass parent-changed notifications are coming from all the children > firing show/hide events, calling getParentCB in the process in the ATK > AccessibleWrap. so, what does the tree we create look like? if its one giant tree we create I'd expect we'd coalesce all the events and only end up firing one hide and one show. I guess its a ton of distinct trees then? > This wasn't an issue prior to the change since we never triggered the full > tree traversal. Removing it would cause issues with the original bug > 814836, though, so I'm not sure how we'd want to proceed. yeah, removing the tree update stuff there would be totally busted. We need to fire fewer events somehow, or fire them faster somehow. (In reply to Jonathan Wei [:jwei] from comment #23) > With regards to IA2, this is not an issue when I tested with NVDA and > current release Thunderbird on the same folder set - there was no noticeable > slowdown when arrowing through. it might be nvda doesn't listen to show / hide events or it does but in process and that's fast enough it doesn't matter.

(In reply to Trevor Saunders (:tbsaunde) from comment #24) > so, what does the tree we create look like? if its one giant tree we create > I'd expect we'd coalesce all the events and only end up firing one hide and > one show. I guess its a ton of distinct trees then? Unfortunately, the hierarchy is as follows: chrome window -> pane -> propertypage -> table -> (one row for each message in the folder) Part of the problem comes from the fact that Thunderbird loads all of the messages at once, without a "load more"-esque solution, but I suppose we won't be changing that behaviour any time soon.

(In reply to Jonathan Wei [:jwei] from comment #25) > (In reply to Trevor Saunders (:tbsaunde) from comment #24) > > so, what does the tree we create look like? if its one giant tree we create > > I'd expect we'd coalesce all the events and only end up firing one hide and > > one show. I guess its a ton of distinct trees then? > > Unfortunately, the hierarchy is as follows: > chrome window -> pane -> propertypage -> table -> (one row for each message > in the folder) that makes sense, but presumably when the selected deck element changes we recreate everythingunder the property page or maybe the pane? that is what are the nodes passed to DocAccessible::ContentRemoved / Inserted?

(In reply to Trevor Saunders (:tbsaunde) from comment #24) > yeah, removing the tree update stuff there would be totally busted. We need > to fire fewer events somehow, or fire them faster somehow. If it is indeed: * all showing/hidden events * for a non-focused tree * that only impacts ATK/AT-SPI2 I am so in favor of firing fewer events. :) I find this statement a tad perplexing however: > it might be nvda doesn't listen to show / hide events or it does but in > process and that's fast enough it doesn't matter. As stated in earlier comments this bug: * You do NOT need Orca to reproduce this bug; just the 9-line (including blanks) pyatspi listener I attached * If you look at the listener, you'll see it only listens for object:state-changed:focused; not object:state-changed:showing. Admittedly, the real-world case is using Orca and Orca does listen to object:state-changed:showing. But spewing out non-registered-for events, while perhaps not this bug, seems like a bug all the same.

1) If we fire tons show/hide then I agree it's rather a problem on our side (I didn't catch what is a cause of those events from John/Trev discussion) 2) If those are ATK only events then we should reduce number of events (fire them on top only), previously delivering all events were crucial for ATK but now it's not iirc 3) Otherwise(and) we could consider to not destroy/create whole trees for switching decks but unattach/attach them from trees, that should save a lot of resources. A trick thing is we have to mutate unattached trees as long as their frame trees mutate

It appears my earlier findings were completely off the mark. When switching to a folder in Thunderbird, the specific event that triggers the whole slowdown is a "show" event on the table with ID 'threadTree' containing all the messages. We send the signal "children_changed:add", which appears to cause ATK to ask for child information for every single child on the object - or for every single message in the folder, which is the source of all the calls to refChildCB/getParentCB. Attached is a quick and dirty patch to the ATK AccessibleWrap to verify this behaviour. children_changed signals aren't sent for an accessible shadowing an element with id 'threadTree', and the slowdown disappears. I'm not sure if there's much that can be done to fix this on the Gecko side, unfortunately. Sending the children_changed:add signal in this case is probably the correct behaviour for when we switch to the new folder.

Adding Piñeiro to the CC list given that he is the ATK maintainer and Jonathan says: > I'm not sure if there's much that can be done to fix this on the Gecko side, unfortunately.

Please is there a way to try doing something about this? With a lot of messages in some folders I think Thunderd is not usable by too many users. I am using it all the time because there is nothing that suits me better at this time however my usage scenario looks like... 0) The message list in account 1 inbox 1 has the system focus. 1) I repeatedly press tab key to go to the folders treeview. 2) I press left arrow key to collapse all the expanded nodes of a folder treeview and sometimes experience a lag. 3) I press down arrow to focus account 2. 4) I press right arrow to expand account 2 and immediatelly press down arrow to focus the inbox for the account 2. 5) Now I feel a horrible lag not knowing when to press the tab key so I can move the focus to the message list for account 2 inbox. Most of the times the processor usage increases during this moment and thunderbird no longer reacts to my keypresses i.e. tab, shift+tab and / or arrow keys. I am used to press ctrl+j to open up the downloads list in this case, tab around inside it as it comes up, then I am closing the downloads list pressing ctrl+w and finally I am able to navigate in the account 2 inbox message list. I have to do this verry frequently it's why I think Thunderbird is not currently suitable for what I consider a normal people. I am afraid you would at best call usage scenario like this unconfortable at least or even something stronger if you were experiencing something like this. Please is there really nothing doable as a community effort to improve the situation regarding this? I really apologize if I sound too demanding however I am afraid I can't do more regarding this issue. If you have some hints or recomendations for me I would be glad to follow them. Finally let me add that this does *not* happen on windows.

I'd be great to have somebody to run profiler and share data here. https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler

Unfortunatelly I am unable to capture a profile my-self. I am able to run Nightly version of Thunderbird, I am also able to install profiler addon into it however what I am unable to figure out is how to run the profiler and take the profile. I can't find its entries inside the menu and it does not appear to react to listed keyboard shortcuts on my machine. I have tried even switching to either english or slovak keyboard layout but still pressing ctrl+alt+1 and / or ctrl+alt+2 does nothing I can notice.

In Thunderbird you should find the controls in the status bar. You should see "disabled". Clicking on that will toggle to enabled. While enabled, click "dump" to save the results

I am sorry I can't follow recommended procedure because in the main thunderbird window I can't use flat review at all thus I am unable to access the statusbar. While a message is showing I can only see a text saying "you are currently online" with no buttons. This part is not keyboard accessible either so currently I can't think of working alternatives to me.

Joanie, maybe you could do a profile? I think it's good to check if there's something to optimize on our side before making Orca to workaround that.

I'll add it to my to-do list. But for what it's worth Orca cannot work around it. As I've stated already in this bug, this problem is independent of Orca. It happens without Orca. You just need the attached listener. And all that attached listener does is listen for object:state-changed:focused events. That's it. Really. :) And I cannot have Orca ignore focused events. Maybe there's something that could be changed in AT-SPI2. <shrugs>

I see the point and thanks!

> Maybe there's something that could be changed in AT-SPI2. <shrugs> assuming comment 29 is correct I think that's where it has to be fixed given all Gecko does is fire one child changed event, and then atk pokes at a ton of children. We could maybe make it a little faster to get each child, but atk will still be doing something that is theta(number of children) and when number of children is 10000 that'll just be slow. Unfortunately I'm not really sure what atk can change, but you need to talk to API about that.

(In reply to Peter Vágner from comment #33) > Unfortunatelly I am unable to capture a profile my-self. I am able to run > Nightly version of Thunderbird, I am also able to install profiler addon > into it however what I am unable to figure out is how to run the profiler > and take the profile. I can't find its entries inside the menu and it does > not appear to react to listed keyboard shortcuts on my machine. I have tried > even switching to either english or slovak keyboard layout but still > pressing ctrl+alt+1 and / or ctrl+alt+2 does nothing I can notice. Yeah, keyboard also does not work for me on windows. > I can't use flat review at all thus I am unable to access the statusbar. I don't understand what you mean. Can you describe it differently, and perhaps post a screen shot?

Okay so we now understand each other at least with saying that it is not possible to start / stop, and capture the profile using profiler addon using the keyboard. Regarding flatreview issue thing you are not getting: Orca screen reader usually reacts to various system events such as focus change, value change etc. This is communicated from Thunderbird using its atk implementation and then through at-spi2 to orca. This all comes into play when the control I am interested in is keyboard accessible and can be navigated to and operated by using the keyboard alone. Since Thunderbird's statusbar and its child icons can't be operated using the keyboard I have no access to it. To try to overcome the situation orca has a feature called flat review built-in. It let's me explore wat's shown on the screen in a 2D like fashion so I can just arrow over all the text content what is on the screen, try to detect statusbar content this way and simulate mouse clicks on that content. Unfortunatelly while using Thunderbird and the main window is showing orca's flat review does not work at all for me. So because I am blind and all the tools and approaches that may help accessing this particular feature to me are either failing conditionally or they are just buggy it meaans I am unable to do that my-self and unfortunatelly someone else will have to capture the profile Alexander Surkov is asking for.

See also this AT-SPI2 bug which, at least from its description and the findings here, sounds like it might be relevant: https://bugzilla.gnome.org/show_bug.cgi?id=650090 ("The at-spi2 cache forces creation of full accessible tree"

Hello, The related at-spi2 bug appears to be significant enough to me at least how I can see it. At the other hand yesterday I have found out a little workaround. When message threading is enabled there are fewer items at the root level and issue is not as critical as with flat message list. When messages are sorted by date and grouping is enabled the issue can no longer be observed. From a developer's point of view does it confirm that at-spi2 bug might be the cause?

I can confirm that this still occurs in thunderbird 31.2.0-1, here in arch linux. Has there been any further progress on this?

@Kendel It appears Mozilla guys are unable to improve the situation regarding this. Now the bal has moved to @gnome_a11y playground https://bugzilla.gnome.org/show_bug.cgi?id=650090

I'd say that the intensive API usage shouldn't ruins out the Firefox. In this case we could expose visible tree items in the accessible tree only when tree items count exceeds the certain number (100? 1000?), doing so we could still expose correct group information. That will make XUL trees similar to ARIA trees and thus it should be workable approach. Not sure about evening, I would avoid to fire tons of show events when the user scrolls the tree. Maybe keeping silent also works.

While the bug happens without Orca running, let's bring Orca back into the picture: The accessibles in the list of messages are only relevant to Orca if and when that list of messages gets focus. So in the bug described here, I'm pretty sure you could completely fail to populate that huge tree, and as long as the user is arrowing up and down in the list of mail folders, Orca (and its users) would be fine. (We should verify this, should you decide it's a possible route to pursue.) You would of course still would need to populate the tree once it gets focus. Your solution in comment 46, as I understand it, might work. I'd have to see it in action. If you have a patch, I could try to set up a Gecko build environment. But maybe there is some way to expose all the children minimally (e.g. implements no interfaces) so that the AT-SPI2 cache creation happens more quickly? Then lazily add the implemented interfaces afterwards?

can try out this one https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/surkov.alexander@gmail.com-0377422745de/ it'd be great to know what was a problem if it didn't work out for you

If you are still tallking about the original issue would it be doable to create a corresponding Thundebird try build? I my-self am unable to trigger this with Firefox although it may still be possible.

(In reply to Peter Vágner from comment #49) > If you are still tallking about the original issue would it be doable to > create a corresponding Thundebird try build? I my-self am unable to trigger > this with Firefox although it may still be possible. oh, here is it https://ftp-ssl.mozilla.org/pub/mozilla.org/thunderbird/try-builds/surkov.alexander@gmail.com-5e72953e3ff0/

Alex: I didn't see this try build. I don't know if Peter did or not. But given the amount of time that has passed, it's no longer there. If you do another build I will try it, and I bet Peter will too.

here's a fresh build https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/surkov.alexander@gmail.com-ecee53762d8c/

Oops. I should have been more clear. Sorry! Like Peter stated in comment 49, I only see the problem in Thunderbird. Could you therefore provide a Thunderbird try build? Thanks, and again, my apologies for not stating that in comment 51.

Thanks Alex. I'm afraid, however, I'm seeing no difference with that try build: It takes a very long time for Thunderbird/Daily to become responsive and AT-SPI2 tells Orca the objects associated with accessible events are defunct. :(

(In reply to Joanmarie Diggs from comment #55) > and AT-SPI2 > tells Orca the objects associated with accessible events are defunct. :( it's a difference between this build and nightly one, right?

(In reply to alexander :surkov from comment #56) > (In reply to Joanmarie Diggs from comment #55) > > and AT-SPI2 > > tells Orca the objects associated with accessible events are defunct. :( > > it's a difference between this build and nightly one, right? Not that I'm seeing. See also this bug against AT-SPI2 I filed the other day: https://bugzilla.gnome.org/show_bug.cgi?id=750531

Joanmarie, https://bugzilla.gnome.org/show_bug.cgi?id=750531 is still open. but is this resolved by bug 1204171?

I am currently running Thunderbird 52.3.0 on Arch linux with Gnome 3.24 and Orca 3.26 and I must say I'm getting a bit lost in this chain of possibly related issues. However the end user experience has not improved for me I am afraid. The horrible lag when switching email folders is still there. Sometimes the CPU spike is that strong that the whole session freezes for me. It takes ages for orca to see and process events e.g. a few minutes to register and react to a keypress. So the only workaround in this case is to kill thunderbird from another tty or from an SSH session. Unfortunatelly there is entirely new thing I am seeing now when trying to reproduce this issue again and again to make sure what I'm saying is definatelly correct. Very often if I leave thunderbird open displaying message list in a folder with a lot of messages (about 5000 is enough I guess), thunderbird will freeze, gnome dialog saying the app is not responding pops up and there is nothing I can do to continue working with thunderbird unless I kill it and start it again. . For example I have been looking through missed emails settling on the recent notification related to this bug. I have opened that message in a new thunderbird window, looked at it, closed the thunderbird message window, leaved thunderbird running with the message list showing, alt+tabbed into firefox to read these 2 mozilla bugs and the related gnome bug in order to remind me about the current situation. Now as I'm typing this comment I hear my laptop fan spinning more and more. By knowing my system I can try to alt+tab back to thunderbird to verify it's frozen and I do need to kill it to prevent hogging all the cpu cycles. I guess the related gnome bug contributes greatly to this awful experience, however thunderbird's flood events only helped to find that gnome issue. I know there are very few people complaining because most of us can do nothing because this does really require certain expertise. But you know this is deal breaker. I am turning to thunderbird because I'm so used to it however when I know I can't risk dealing with its freezes for example working together with a friends or colleagues I'm turning to either web based Roundcube to look at my emails or emacs gnus. We desperatelly need this addressed somehow or we need to make thunderbird add a kind of paging to its message list as handling more than some 1000 messages in a single folder is not usefull at all.

https://bugzilla.gnome.org/show_bug.cgi?id=650090 was resolved long ago in 2015. So what's left here, just https://bugzilla.gnome.org/show_bug.cgi?id=750531 and the old patch?

Clearing the NEEDINFO as I don't know what remains to be done, but Peter indicates in comment 59 that it's still a problem.