gtk_widget_get_accessible may be called while AT is disabled if may cause nsAccessibilityService::GetAccessibleFor () being called, and then nsAppRootAccessible::Init (). finally atk_bridge_init() Our gconf key and GNOME_ACCESSIBILITY checking is bypassed. You can find the stack at http://bugzilla.gnome.org/show_bug.cgi?id=377568

DOM inspector, View->Show Accessible Nodes may cause this issue, too.

(In reply to comment #0) > gtk_widget_get_accessible may be called while AT is disabled when does it happen? (In reply to comment #1) > DOM inspector, View->Show Accessible Nodes may cause this issue, too. shouldn't DOMi do that? Do you mean crossplatform a11y start should run linux a11y?

(In reply to comment #2) > (In reply to comment #0) > > gtk_widget_get_accessible may be called while AT is disabled > > when does it happen? e.g. yelp embeds Gecko, and it calls gtk_widget_get_accessible() for the Gecko widget. > (In reply to comment #1) > > DOM inspector, View->Show Accessible Nodes may cause this issue, too. > > shouldn't DOMi do that? Do you mean crossplatform a11y start should run linux > a11y? I meant we should never do atk_bridge_init() when a11y is disabled in gconf key or GNOME_ACCESSIBILITY env variable. We can have xp a11y enabled in this situation but should not activate atk-bridge. Honestly, I don't know if this bug is still valid.

(In reply to comment #3) > (In reply to comment #2) > I meant we should never do atk_bridge_init() when a11y is disabled in gconf key > or GNOME_ACCESSIBILITY env variable. > We can have xp a11y enabled in this situation but should not activate > atk-bridge. ok, that makes sense I think

AUTO-CLOSED. This bug untouched for over 2000 days. Please reopen if you can confirm the bug and help it progress.