After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 639685 - Orca Application preferences dialog closing very slow
Orca Application preferences dialog closing very slow
Status: RESOLVED FIXED
Product: orca
Classification: Applications
Component: general
2.91.x
Other All
: Normal normal
: ---
Assigned To: Orca Maintainers
Orca Maintainers
Depends on:
Blocks: 491756
 
 
Reported: 2011-01-16 17:50 UTC by Hammer Attila
Modified: 2012-08-15 10:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Debug file with showing some application-specific and normal Orca preferences dialog opening and closing. (378.48 KB, application/octet-stream)
2011-01-16 17:50 UTC, Hammer Attila
Details
debug output file (45.78 KB, application/x-gzip)
2011-08-17 08:43 UTC, Victor Ramirez (virako)
Details
debug output files (6.95 KB, application/x-gzip)
2011-09-22 16:50 UTC, Victor Ramirez (virako)
Details

Description Hammer Attila 2011-01-16 17:50:50 UTC
Created attachment 178452 [details]
Debug file with showing some application-specific and normal Orca preferences dialog opening and closing.

Dear Developers,

I see big performance speed difference with Orca preferences dialog (Orca+Space) and Orca Application-specific preferences dialog closing speed.
For example if I launch Yelp application, simple opening the Orca application-specific preference dialog and closing the dialog with Esc key or clicking Ok button to save new preferences, I need waiting 10 second before Orca is begin talking again.
When I using normal Orca preferences dialog command (Orca+Space keystroke), I need waiting only 3 second if I closing preferences dialog.
I see similar time difference values with Gedit, Firefox applications, I think this is not depending what application are launched.

Reproducation steps if you would like testing this problem or verify:
1. Launch any application, for example Firefox or Yelp.
2. Press Orca+Ctrl+Space keystroke.
3. Simple press Esc key to close the dialog, or click OK button.
You need wayting 10 second to Orca speech again.

Attila
Comment 1 Joanmarie Diggs (IRC: joanie) 2011-01-16 17:56:25 UTC
Thanks for filing this bug Attila!

I'm going to block the performance metabug so it gets added to the work done during the performance analysis.
Comment 2 Victor Ramirez (virako) 2011-08-17 08:43:57 UTC
Created attachment 194015 [details]
debug output file

Debug file with showing yelp application-specific and normal Orca preferences
dialog opening and closing.
Comment 3 Victor Ramirez (virako) 2011-08-17 08:44:42 UTC
I have checked this problem in orca-xdesktop and I have the same problem that Attila. Although I have checked this problem with Orca 3.1.5pre and this problem seems solved.
Comment 4 Victor Ramirez (virako) 2011-09-22 16:50:12 UTC
Created attachment 197267 [details]
debug output files

I have checked this problem in orca 3.2.0pre, the problem seems be that occurs a lot of event, althought closing the orca's preferences no exists delay.

I attach two debug files ( 3.2.0.pre and 3.2.0.pre-xdesktop ), I have used Ubuntu natty (11.04) and Firefox 6.0.2. 

I followed the steps the description by Atila. I used key Escape for close preferences. 

This bug is similar to bug 638970, althought I believe the bug 638970 might be for the problem of delay load profile, and this bug for the delay preferences close.
Comment 5 Joanmarie Diggs (IRC: joanie) 2012-08-14 20:52:36 UTC
Attila can you still reproduce this bug with Orca 3.5.x?
Comment 6 Hammer Attila 2012-08-15 05:32:48 UTC
No, now about 5 second later after clicking OK button focus jumping back the used application if I using Orca modifier+CTRL+Space key combination.

Attila
Comment 7 Joanmarie Diggs (IRC: joanie) 2012-08-15 10:28:13 UTC
Thanks Attila.  And the "jumping back" bit taking 5 seconds is (I suspect) bug 638970. Since we have a bug for the remainder of the delay, I'm closing this one.