Nautilus is very slow in list mode with Assistive Technologies enabled (at-spi)

Bug #159042 reported by despotakisch
88
This bug affects 11 people
Affects Status Importance Assigned to Milestone
ATK
Expired
Critical
Nautilus
Invalid
Undecided
Unassigned
atk1.0 (Ubuntu)
Invalid
Low
Ubuntu Desktop Bugs
Nominated for Lucid by Charlie Kravetz

Bug Description

When I open a folder with many files (for example '/usr/lib', '/usr/bin') Nautilus is very very slow in 'List View' if Assistive Technologies is enabled.

Disabling Assistive Technologies via the preferences dialog restores performance: opening a large folder takes a second or two rather than 30 seconds or more.

Revision history for this message
royden (ryts) wrote :

I suggest seeing if you have assistive technology enabled and if so disable it, reboot.

"preferences" -> "Universal Acess" -> etc.

Note to devs: this one can kill the nautilus experience :-)

ryts

Revision history for this message
despotakisch (despotakisch-gmail) wrote :

It's O.K. Thanks.

Revision history for this message
Carey Underwood (cwillu) wrote : Re: Nautilus is very slow in list mode with assistive technologies enabled

Still broken in intrepid.

description: updated
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find.

Changed in nautilus:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Invalid
Revision history for this message
Sebastien Bacher (seb128) wrote :

not sure that"s a duplicate but that's similar to bug #267051

Changed in nautilus:
status: Invalid → New
Revision history for this message
wribeiro (wribeiro) wrote :

Ubuntu 8.10 cames with assistive technologies enabled by default and it means that a large amount of users will have performance problems in Nautilus and maybe the importance of this bug should be increased.
I spent a long time to discover that turning off the assistive technologies could be a work around for this.

Revision history for this message
Zakhar (alainb06) wrote :

Thank's for the workaround wribeiro.

I do confirm the bug as of Intrepid.

Moreover, if you switch Nautilus to Tree View, and try to open the tree (not click the directory, just click the triangle to open the tree) on a directory such as /usr/share that contains around 300 other directories (325 on my system), it in not slow, it is EXCRUCIATINGLY slow!

On my system (laptop Core 2 Duo / 2,4GHz, 4GB RAM, / on ext3 partition) I killed the tree opening after 10 minutes on my watch. The killing process itself needs 30 seconds! All the time processor was at 100% and the disk didn't seem to be seeking a lot.

When assistive technology is turned off, it opens in no time (less than 1 sec).

This is really a bad thing for accessibility which ought to be part of Free Software philosophy. And bad for everyone, as wribeiro is right, this option is on by default with Intrepid.

Revision history for this message
horst (autotier) wrote :

Another reason why this bug's importance level should be increased is that one needs assistive technologies in order to get rid of either the incredibly annoying minimize animation or the wireframe while moving windows. Please fix this. Cheers.

Revision history for this message
Pedro Villavicencio (pedro) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Could you try to reproduce the same with Ubuntu 9.04? Thanks in advance.

Changed in nautilus:
status: New → Incomplete
Revision history for this message
DLCBurggraaff (burdi) wrote :

When doing some research for #292707 came accross this bug.
I found that in both Intrepid and Jaunty the disabling the Assistive Technologies (and logging out and in again) makes the problem go away.

Revision history for this message
vocx (eliudcabrera) wrote : Backtraces

This is related to bug #267051. You can tell by the upstream bug report.

A similar Debian bug report is here
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506715

Note how the "at-spi-registryd" process appears next to nautilus.

I'm attaching 3 gdb backtraces.

To obtain these:
    1. Install debug packages "nautilus-dbg", "libgtk2.0-0-dbg", "libglib2.0-0-dbg", "libatk1.0-dbg".
    2. Completely close nautilus with "nautilus --quit"
    3. Run the debugger "gdb nautilus" as described here https://wiki.ubuntu.com/Backtrace
    4. I try to open /usr/bin which is guaranteed to have at least 1500 files.
    5. Nautilus will eventually load the directory, but you need to wait at least 2.5 minutes on a slow computer. The time increases with the number of files.
    6. Interrupt the process in the terminal with Ctrl+C. You may do this while nautilus is still unresponsive; if you wait for it to finish loading the directory you won't have anything interesting in the backtrace.

In the first backtrace the only library without symbols is "/usr/lib/gtk-2.0/modules/libatk-bridge.so", which is included in the "at-spi" package, which also provides "/usr/lib/at-spi/at-spi-registryd"

    7. To obtain the other two backtraces install the debug symbols for this library, which are found in "libatspi-dbg"
    8. Briefly looking at the source code in gail/gailtreeview.c, iterate_thru_children() is a recursive function, and according to one backtrace it is called a gazillion times.
    9. The other backtrace shows a different output. You can run gdb several times to get different outputs each time, depending on the moment you hit Ctrl+C. I tested this on a single core, AMD64 processor, running 32-bit Ubuntu 8.10. If you have a multicore machine, you'll see threads everywhere in the backtraces.
   10. Running "valgrind" with nautilus takes a LOT of time to even start. It outputs several lines concerning python2.5 and python libraries, which I believe is totally unrelated to this bug.

 ECC

Revision history for this message
Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount) wrote : Re: Nautilus is very slow in list mode with assistive technologies enabled

This is still an issue with Ubuntu 9.04 (Jaunty). You can easily reproduce doing the following:
1. Enable Assistive Technology
2. logout and login
3. Open nautilus and choose list view
4. Navigate to the folder "/usr/lib"
5. See how long it takes (it becomes unresponsible for some time)
6. Deaktivate Assistive Technology
7. logout and login
8. Do as in step 3 + 4
9. Feel the difference

Changed in nautilus:
status: Incomplete → Confirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :

could somebody open the bug on bugzilla.gnome.org?

vocx (eliudcabrera)
description: updated
Revision history for this message
UeB (moritz-nadler) wrote :

I can confirm this bug.

I think the importance should be higher then "low" because I think it is a shame when I file browser sucks at browsing through directories and showing files.

Revision history for this message
Marko Martinović (marko-martinovic-deactivatedaccount) wrote :

I can confirm this bug too. Shame for people like me who need Asisstive Tech turned on to use pc. Low? If developers need it every day like us ill people need it it would have Critical importance flag. Shame...

Revision history for this message
Benny (benny-malengier) wrote :

This is present in the GTK app GRAMPS too on the treeviews, making the user experience in GNOME _very_ bad.
Does somebody know if an app can opt out of ATK?
Is there an upstream bug?

As an application developer I can only say: turn ATK off as long as it does not work. People with disabilities surely can find somebody to turn it on the first time they want to use a PC?
You are destroying the GTK applications like that in favour of their competitors!!

Revision history for this message
jerryb (gerald-britton) wrote :

The way ATK affects GTK apps is a real blocker for me. I vote strongly to have it disabled by default. It is certainly easy to enable with the Assistive Technologies applet, for those who really need it.

Revision history for this message
Benny (benny-malengier) wrote :

Can this bug be linked to upstream: http://bugzilla.gnome.org/show_bug.cgi?id=419383

A workaround (??) for apps is given there, however, not very satisfactory. Unattaching the model and reattaching after every little change is not what the GTK API says.

Revision history for this message
Sebastien Bacher (seb128) wrote :

could somebody having the issue open a GNOME bug on the right component (nautilus or gtk)?

replying to the comment 17 accessibility is not enabled by default

Changed in nautilus (Ubuntu):
status: Confirmed → Triaged
status: Triaged → Confirmed
Revision history for this message
Benny (benny-malengier) wrote :

I opened a bug against atk: http://bugzilla.gnome.org/show_bug.cgi?id=587020
I hope that is the correct place to get attention

Changed in atk:
status: Unknown → New
Revision history for this message
Benny (benny-malengier) wrote :

Upstream ATK bug http://bugzilla.gnome.org/show_bug.cgi?id=577098 is an earlier version.

If the analysis there is correct, then ATK is unmaintained since 2005 when Sun worked on it, and future work is planned only for Gnome 3.0 ( http://live.gnome.org/Accessibility/BonoboDeprecation )

I suppose Canonical can see if this is indeed the case by contacting GNOME devels and/or the people of codethink http://codethink.co.uk/ who plan to work on it for gnome 3.0

If indeed there are no developers that take up these serious issues, I would suggest to completely remove ATK from Ubuntu. THere is no place in a mainstream distro for broken technologies that interfere with other applications and no developers to take up the issues.

Changed in nautilus (Ubuntu):
status: Confirmed → Triaged
Changed in nautilus:
status: New → Invalid
Revision history for this message
DLCBurggraaff (burdi) wrote :

@Martin May:
An explanation of the "status: New -> Invalid" change would be appreciated.
Regards, Dick

Revision history for this message
vocx (eliudcabrera) wrote : Re: [Bug 159042] Re: Nautilus is very slow in list mode with Assistive Technologies enabled (at-spi)

DLCBurggraaff

It was set as "invalid" in Nautilus, because it is not a bug in Nautilus itself, but rather a bug within the accessibility (ATK) libraries. That is, this bug should manifest itself in other programs using GtkTreeView widgets and with accessibility turned on.

This does not mean the bug will be neglected, only that the real cause has been determined more precisely.

ECC

--- On Wed, 29/7/09, DLCBurggraaff <email address hidden> wrote:

> From: DLCBurggraaff <email address hidden>
> Subject: [Bug 159042] Re: Nautilus is very slow in list mode with Assistive Technologies enabled (at-spi)
> To: <email address hidden>
> Date: Wednesday, 29 July, 2009, 11:52 AM
> @Martin May:
> An explanation of the "status: New -> Invalid" change
> would be appreciated.
> Regards, Dick
>
> --
> Nautilus is very slow in list mode with Assistive
> Technologies enabled (at-spi)
> https://bugs.launchpad.net/bugs/159042
> You received this bug notification because you are a direct
> subscriber
> of the bug.
>

Revision history for this message
Pedro Villavicencio (pedro) wrote :

reassigning to atk then, thanks for the info.

affects: nautilus (Ubuntu) → atk1.0 (Ubuntu)
Revision history for this message
tc7 (tc7) wrote :

Been struggling with "large" directories for weeks - anything over a few hundred files renders nautilus almost useless.
I'd previously disabled all preview on images etc, but still took up to 1 minute to display large directories with images (for example).

Running Jaunty with 2 GB RAM, 2.4 GHz quad and NVIDIA 8600GT.

Once Assistive Technolgies was disabled (in System - Control Centre. Then logout and back in again)...
It's still not instantaneous, but can display up to 1000 files in a directory in a few seconds (the icons gradually appear thereafter). A vast improvement.

Wow! FInally I have a usable file manager!

(I feel sorry for those that may rely on AT)

Revision history for this message
molecule-eye (niburu1) wrote :

This bug (apparently in AT and not Nautilus) is still present in Ubuntu 9.10 Karmic. If I needed AT this would be enough to have me moving to KDE.

Does this affect other file browsers for gnome?

Revision history for this message
Sebastian (guttenb) wrote :

I can confirm: Still present in Karmic. Had a hard time to find that it's due to AT. Reading the history of this old bug I am really astonished that it's not taken more serious. If there is no fix, there could at least be a warning, when enabling AT (which should be disabled by default then).

description: updated
Revision history for this message
hariprasad (hariprasad) wrote :

On Lucid Lynx 10.04, this bug endures. Even if Assistive Technolologies are off, 500 files in directory takes on AMD Phenom X4 925 (MSI 890GXM) a few minutes to response. It is really very slow.

Revision history for this message
DLCBurggraaff (burdi) wrote :

@hariprasad
It looks like most (all but you?) people after switching off the Assistive Technologies no longer experience the slowdown. In other words, your problem may be something completely different. I would recommend opening a new bug.
Kind regards, Dick

Changed in atk:
importance: Unknown → Critical
Revision history for this message
Charlie Kravetz (cjkgeek) wrote :

This issue is not present in Maverick Meerkat, Ubuntu 10.10. It is a serious issue in Ubuntu 10.04 LTS, and needs to be fixed as soon as possible.

Changed in atk1.0 (Ubuntu):
status: Triaged → Fix Released
status: Fix Released → Invalid
Changed in atk:
status: New → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.