Last Comment Bug 393398 - Add Bookmarks Dialog Inaccessible
: Add Bookmarks Dialog Inaccessible
Status: RESOLVED FIXED
: access, relnote, sec508
Product: Firefox
Classification: Client Software
Component: Bookmarks & History (show other bugs)
: Trunk
: All All
: P3 major with 1 vote (vote)
: Firefox 3 beta3
Assigned To: Aaron Leventhal
:
Mentors:
Depends on: 409623
Blocks: 279703 385266 fox3access
  Show dependency treegraph
 
Reported: 2007-08-23 06:47 PDT by Tim Keenan
Modified: 2010-02-24 06:28 PST (History)
21 users (show)
mconnor: blocking‑firefox3+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
screenshot (11.38 KB, image/jpeg)
2007-08-23 07:41 PDT, Joanmarie Diggs
no flags Details

Description Tim Keenan 2007-08-23 06:47:29 PDT
Pressing ctrl+d yields the "context menu" from Window-eyes.  Accessing the same functionality through the menus yields no speech.  The dialog, if there is one, can't be found by reviewing the window either.
Could someone with Accerciser tell me what they get on the Linux side.  I'll try to get accexplorer to cooperate ude Windows and find out what's going on.
Comment 1 Joanmarie Diggs 2007-08-23 07:41:29 PDT
Created attachment 277901 [details]
screenshot

This seems to be another instance of a re-purposed menu that's not really a menu (see my comment on bug 393248).

What I'm seeing in Linux is a menu that is the direct descendant of the application frame.  The children of this menu are not menu items (as one would expect), but instead labels and entries and push buttons.  

It would seem that when menus are pretending to be dialogs, not only do assistive technologies get confused, but keyboard navigation does as well.  The logical way to move in something that looks like a dialog would be to press Tab.  But when I do this, I move among focusable items (links, form controls, etc.) in the page I'm viewing. 

In addition, admittedly minor given the above, the text for the Delete and Done push buttons seems to be mis-aligned so that the vertical center of each word is the bottom edge of the button.  See attached screenshot.
Comment 3 Dão Gottwald [:dao] 2007-08-24 01:12:45 PDT
(In reply to comment #1)
> This seems to be another instance of a re-purposed menu that's not really a
> menu

Could this be a <panel> bug then? If I understand the purpose of that widget correctly, it shouldn't pretend to be a menu.
Comment 4 Tim Keenan 2007-08-27 14:09:11 PDT
An upcoming version of Jaws can successfully interact with the interface, but the panel doesn't get focus on activation of the Add Bookmark menu item or ctrl+d.  It still characterizes the interface as a menu, yet it lets you tab through it like a dialog.  I'm never come across anything quite like it.
Comment 5 Tim Keenan 2007-09-05 14:47:49 PDT
This has been updated so at least escape will close the panel, but it's still reported as a menu and Window-eyes can't track focus movement within it.  How about Orca?
Comment 6 Tim Keenan 2007-09-11 11:13:22 PDT
This is nicely fixed in the 09-11-04 build.  Thanks, someone.
This looks fine with inspect32 and windows screen-readers.  
I'm marking this as resolved-fixed since Windows and Linux seem to jibe very closely on things like this.
Someone should certainly confirm it on Linux, though.
Comment 7 Mike Pedersen 2007-09-11 11:25:59 PDT
This does now seem to be working much better on linux.  There is a problem of no labels for the two edit fields in this dialog but that should probably be another bug.  
Comment 8 Tim Keenan 2007-09-13 14:59:25 PDT
I'm going to reopen this, because Window-eyes still doesn't track this correctly and claims it's a menu, in addition to the edit field problems.
I apologize for jumping the gun on this.  I'm not sure what happened on my end when I claimed everything was mysteriously working.  
It does work with Jaws, and there are improvements with Linux, but there's still work to be done.
Comment 9 Aaron Leventhal 2007-10-05 13:59:38 PDT
*** Bug 392580 has been marked as a duplicate of this bug. ***
Comment 10 Joanmarie Diggs 2007-10-11 07:26:47 PDT
While Orca can deal with this "dialog", I still question why it has the role of menu rather than dialog.
Comment 11 Tony Chung [:tchung] 2007-11-14 11:22:39 PST
keywording relnote for b1
Comment 12 Aaron Leventhal 2007-12-08 16:01:08 PST
I have a partial fix for this in bug 407359, although when it closes focus needs to go somewhere reasonable.
Comment 13 Marco Zehe (:MarcoZ) 2007-12-09 10:56:56 PST
(In reply to comment #12)
> I have a partial fix for this in bug 407359, although when it closes focus
> needs to go somewhere reasonable.

I would suggest to return to the page content. This is how the popup behaves without your patch for bug 407359, which I am testing right now.
Comment 14 Aaron Leventhal 2007-12-09 17:54:21 PST
I should have been more specific. There's a problem with where focus goes after you hit Escape. That isn't affected by my patch in bug 407359.
Comment 15 Marco Zehe (:MarcoZ) 2007-12-10 01:58:09 PST
(In reply to comment #14)
> I should have been more specific. There's a problem with where focus goes after
> you hit Escape. That isn't affected by my patch in bug 407359.

Yes it is affected. :-) Without your patch, hitting ESCAPE from Add Bookmarks drops me back to Page Content. With your patch, hitting ESCAPE puts me in la-la-land, and I have to hit TAB to get to the Location bar.
Comment 16 Aaron Leventhal 2007-12-10 07:32:20 PST
I tested in nightly builds which don't have the patch. Pressing Escape puts focus in lala land there too. You have to hit tab to move focus.
Comment 17 Aaron Leventhal 2008-01-22 07:46:41 PST
Fixed by checkin to bug 407359.
Comment 18 tkeenan79 2008-01-25 15:21:38 PST
This is still broken on today's build with Window-eyes.  Did this fix work for Orca users?  Pressing ctrl+d speaks the name edit box, but no more.  Tab results in nothing, however, if I down-arrow in the list of folders, Window-eyes will read that sluggishly.  Hitting escape returns me to the page content.
Comment 19 Marco Zehe (:MarcoZ) 2008-01-28 15:37:53 PST
(In reply to comment #18)
> This is still broken on today's build with Window-eyes.  Did this fix work for
> Orca users?

Yes, it definitely did fix things for Orca users. Note that you have to have the January 24, 2008 build or newer for the fix to be in.
Comment 20 Tony Chung [:tchung] 2008-01-30 21:51:38 PST
marco, has this fix been verified on trunk?  if so, please mark the status to "Verified", and include the build ID you verified it on.  thanks.
Comment 21 tkeenan79 2008-01-31 00:38:23 PST
Window-eyes still doesn't seem to be able to track the focus.  I haven't noticed an appreciable change from prior to the January 24 build.  Window-eyes doesn't treat it like a dialog the way Jaws does.  Tabbing yields nothing, as before.  If there's nothing more you can do on this end, I'll talk to the GW Micro folks and see what they can do.  
Comment 22 Aaron Leventhal 2008-01-31 05:41:17 PST
Tim, I suspect we need to get feedback from Window-Eyes on what the issue is.
Comment 23 Tony Chung [:tchung] 2008-06-03 16:36:55 PDT
(In reply to comment #21)
> Window-eyes still doesn't seem to be able to track the focus.  I haven't
> noticed an appreciable change from prior to the January 24 build.  Window-eyes
> doesn't treat it like a dialog the way Jaws does.  Tabbing yields nothing, as
> before.  If there's nothing more you can do on this end, I'll talk to the GW
> Micro folks and see what they can do.  
> 

Hi Tim, if this is still an open issue, can you reopen the bug?  thanks.
Comment 24 tkeenan79 2008-06-03 17:18:06 PDT
This was fixed on GW Micro's end.
Comment 25 Marco Zehe (:MarcoZ) 2008-06-10 09:56:26 PDT
Mike, please update the final relnotes for Firefox 3 as follows:

- Remove the sentence that says "Using JAWS iss recommended".
- Add a sentence to the effect "GW Micro has fixed this problem in an upcoming Window-Eyes release."

Thanks!
Comment 26 Samuel Sidler (old account; do not CC) 2008-08-29 18:11:19 PDT
fwiw, I updated the release notes to note that this is fixed in an upcoming Window-Eyes release.
Comment 27 Gervase Markham [:gerv] 2009-11-26 06:38:27 PST
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv

Note You need to log in before you can comment on or make changes to this bug.