417578 - New Firefox windows don't exist in AT-SPI until they are focused

Status: VERIFIED FIXED

(Firefox :: Disability Access, defect)

Description

[Zack Cerza]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008021019 Fedora/3.0b4pre-0.beta2.18.nightly20080210.fc9 Minefield/3.0b4pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008021019 Fedora/3.0b4pre-0.beta2.18.nightly20080210.fc9 Minefield/3.0b4pre

In previous versions of Firefox, the AccessibleApplication's children were updated as soon as windows were created in the UI. Currently they are not created until the windows are actually focused. The first window created when Firefox is first launched, however, is created immiediately as expected.

Reproducible: Always

Steps to Reproduce:
1. Start Firefox
2. Create a new window
3. Check the children of Firefox's root AccessibleApplication
Actual Results:  
There is only one child (the original window) until the second one is focused.

Expected Results:  
There should be two children (the original window and the new one).

Comment 1

[Marco Zehe (:MarcoZ)]

(In reply to comment #0)
> In previous versions of Firefox, the AccessibleApplication's children were
> updated as soon as windows were created in the UI. Currently they are not
> created until the windows are actually focused. The first window created when
> Firefox is first launched, however, is created immiediately as expected.

Zack, what does "in previous versions" imply? Can you give us an exact build number where this broke for you? E. G. was 2008020804 still fine, and 2008020904 broken, or something similar?

Comment 2

[Aaron Leventhal]

Working on this in bug 417828

Comment 3

[Zack Cerza]

Oops, I don't normally leave important information out like that :)

Currently I am on 20080210 and will update it at some point today. I think this might have been the first build that I noticed this bug, but I could be wrong. At first I didn't realize it was a bug; I thought I was doing something wrong. The latest version I can be positive that didn't have this bug is the 2.0.x series, I'm sorry.

Comment 4

[Aaron Leventhal]

Zack, can you see if the fix for bug 412878 fixes this? I have some try server builds posted in there if you don't want to build it yourself.

Comment 5

[Zack Cerza]

Aaron, I'm getting "Access Denied" trying to look at that bug.

Comment 6

[Zack Cerza]

Ok, I tried [e-mail]-DocLoadFixes_417249_417828_417578-firefox-try-linux.tar.bz2. I can't seem to reproduce the behavior I saw, which is good. 

But I also am not seeing any document:load-{stopped,complete} events get fired at all. I've never looked for those before, though. Perhaps I'm doing something wrong.

Comment 7

[Aaron Leventhal]

Ok. Please comment in that bug too then.

Comment 8

[Aaron Leventhal]

Fixed via checkin to bug 417249.

Comment 9

[Aaron Leventhal]

Zack, can you verify this is fixed and that you get doc load completed events?

Comment 10

[Zack Cerza]

Aaron,

With the build at bug #417249 comment #24, this bug seems to be fixed but bug #417249 isn't - I still have yet to see a single document: event.

Comment 11

[Aaron Leventhal]

Zack, that was the wrong build to test, sorry. The trunk has even more fixes now. You can try this one: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/fx-linux-tbox-trunk/

Or wait until tomorrow. Or take Scott Haeger and Ginn's word for it on bug 417249.

Comment 12

[Aaron Leventhal]

In the meantime you can mark this one VERIFIED.

Comment 13

[Zack Cerza]

VERIFIED indeed. Still not seeing document: events on today's trunk :(

Comment 14

[Aaron Leventhal]

Not today's trunk builds -- or are you building from source?

There is a link to a working tinderbox build in comment 11 which has more than today's trunk builds.

Comment 15

[Zack Cerza]

oh, ok. It was the one in comment 11; I just misunderstood it to be "trunk".