STR: 1. Build mozilla-central Firefox with --enable-accessibility on the Mac. 2. Start VoiceOver with Cmd+F5, and then start this build. 3. Answer whatever you prefer for the "Default browser" question. 4. The Minefield start page should come up by default. If not, open the above URL. 5. Patiently navigate through the HTML content with Ctrl+Option+RightArrow. Result: 1. Initially, VoiceOver cursor is on the "Skip to main content" link. 2. Next, it goes to a "list" element. Expected would be to go to the H1 which has the "Mozilla" link in it, but VO skips right over it. 3. Next it goes to the "Search Mozilla" textbox. 4. Next it goes to the "Go" button, but doesn't announce it as a button. 5. Next, it jumps directly to the "Minefield icon" image. Expected would be to jump to the H1 element with "Welcome to Minefield!" text. 6. ...And so forth. More STR: 6. Press Ctrl+Option+I to bring up Item Chooser. Expected: All text and other elements should be present. Actual: Only links, the lists, buttons, the textfield and images are visible, but none of the plain text objects.
Is this something that used to work in FF, but no longer does? If so please try to find a regression range.
Håkan, do you know? (see comment #1)
I haven't tried or worked on this in ages, but I think it used to work, yes. Maybe Marco knows better.
I built Firefox 3.0/Granparadiso from source today, and this problem exists there, too. So whatever the bug, it's been in our codebase for a long time.
Sorry I've taken so long to get back to this. Things now seem much worse than when you opened this bug ... but I've no idea why. I just compiled mozilla-central (code pulled this Monday, 2009-08-17) with --enable-accessibility, and failed to get even the most basic VoiceOver commands to work in it. Even Cmd-F5 to turn on VoiceOver doesn't work when this build has the focus! And that works fine on current nightlies (made without --enable-accessibility). Marco, what do you see when you build mozilla-central from current code with accessibility enabled? I should also mention that *all* the accessibility mochitests fail.
Same thing is true on the 1.9.1 branch (also using code pulled Monday, 2009-08-17).
Though on the 1.9.1 branch, only 39 mochitests fail and 73 do pass :-)
Steven, the tinderboxes seem to disagree with you, since the Mac a11y tests are all passing there on both branches that we run them on: Firefox and Firefox3.6. I haven't built on Mac in recent weeks, but will try it out over the weekend to see hwat I get. But right now, I'm leaning toward something having changed in your configuration that breaks you so badly. Although I have no idea what that might be.
Confirmed, situation on my MB with the source pulled today is the same as it was when I filed the bugs, no situation change for the better OR worse.
So I need to figure out what I did wrong :-( I didn't realize we had tinderboxes doing Mac builds with --accessibility-enabled. Are they publicly accessible? Where are they? Do they have logs indicating what .mozconfig files they're using? For the record, here's the .mozconfig I've been using: export CFLAGS="-g -gfull" export CXXFLAGS="-g -gfull" . $topsrcdir/browser/config/mozconfig mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-firefox mk_add_options MOZ_MAKE_FLAGS=-j4 mk_add_options AUTOCONF=autoconf213 ac_add_options --enable-optimize ac_add_options --enable-tests ac_add_options --enable-cpp-rtti ac_add_options --enable-logrefcnt ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.4u.sdk ac_add_options --enable-accessibility
Turns out I was wrong about the accessibility mochitests -- I was running them the wrong way. The correct way (which I don't believe is documented anywhere) is: 1) Change to the [objdir]/_tests/testing/mochitests directory. 2) Run 'python runtests.py --a11y'
> I didn't realize we had tinderboxes doing Mac builds with > --accessibility-enabled. Are they publicly accessible? Where are > they? Do they have logs indicating what .mozconfig files they're > using? I've figured out the answers to these questions. The "OS X 10.5.2 mozilla-central unit test" tinderboxes are running a11y mochitests. Their mochitest files are listed in their logs. They aren't much different from the one I've been using. But I'll play with the differences and see what I can find out.
The try-server build from here: http://email@example.com/ fixes this bug. It contains the fixes for bug 712923 and bug 712927.
I believe fixing bug 712923 finally addressed that, as well as previous fixes. I haven't checked without the fix for bug 712927 though. But it will land soon. If there is anything specific missing, still, please file a more specific bug. Thanks.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 712923
You need to log in before you can comment on or make changes to this bug.