Closed Bug 417578 Opened 17 years ago Closed 17 years ago

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

Categories

(Firefox :: Disability Access, defect)

x86
Linux
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: zcerza, Assigned: ginnchen+exoracle)

Details

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).
Assignee: nobody → ginn.chen
(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?
Working on this in bug 417828
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.
Summary: New Firefox windows aren't visible in AT-SPI until they are focused → New Firefox windows don't exist in AT-SPI until they are focused
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.
Aaron, I'm getting "Access Denied" trying to look at that bug.
Ok, I tried aaronleventhal@moonset.net-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.
Ok. Please comment in that bug too then.
Fixed via checkin to bug 417249.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Zack, can you verify this is fixed and that you get doc load completed events?
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.
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.
In the meantime you can mark this one VERIFIED.
VERIFIED indeed. Still not seeing document: events on today's trunk :(
Status: RESOLVED → VERIFIED
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.
oh, ok. It was the one in comment 11; I just misunderstood it to be "trunk".
You need to log in before you can comment on or make changes to this bug.