448836 - Name entry of Add Bookmark dialog does not initially emit caret-moved events

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect, P1)

Description

[Joanmarie Diggs]

Steps to reproduce:

1. Choose Organize Bookmarks
2. Select Bookmarks Menu in the tree on the left
3. Organize -> New Bookmark
4. Type a name then arrow left amongst the characters

Expected results: Caret-moved events would be emitted.
Actual results: Caret-moved events are not emitted.

5. Tab to Location
6. Shift+Tab back to Name
7. Type a name then arrow left amongst the characters

At this point caret-moved events are emitted.

Seems to be a regression which took place around 17 July.

Works as expected:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1a1pre) Gecko/2008071622 Minefield/3.1a1pre

No longer works as expected starting:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1a1pre) Gecko/2008071723 Minefield/3.1a1pre

Comment 1

[Marco Zehe (:MarcoZ)]

This is a regression from bug 345759. See:
http://hg.mozilla.org/mozilla-central/index.cgi/shortlog/fd6a651efed4

Comment 2

[alexander :surkov (:asurkov)]

we register selection listener but we never get NotifySelectionChanged callback. If you'll change focused element then we reregister selection listener and callback is called.

Comment 3

[alexander :surkov (:asurkov)]

layout module calls NotifySelectionChanged methods but it seems there is no registered a11y object because our callback isn't called (nsCaretAccessible:: NotifySelectionChanged), possibly the reason is they recreate selection object.

Comment 4

[Trevor Saunders (:tbsaunde)]

I can reproduce this with 4.010pre  the nightly for yesterday, open the show all book marks entry, and  use the trees to select a bookmark or folder.  Then tab to the name field and try to arrow left or right you should see caret-moved events, but won't.  Then tab to the location field and observe the same issue.  However this issue is not present with the search field.

Comment 5

[Trevor Saunders (:tbsaunde)]

I was just looking at thunderbird, and noticed that in the new account dialog the fields for name, email, and password have the same issue.  Also note that unlikethe initial report this issuedoesn't go away if you taab away and then back.  I'm not sure if the thunderbird issue is different but it seems like its the same.  I'm also not sure this is the same problem as the initial bug since it doesn't go away if you ab away back.

Comment 6

[alexander :surkov (:asurkov)]

Trevor, can you retest it against nightlies please, the way we create accessible tree is changed so since it looks like a timing issue then it might gone.

Comment 7

[Trevor Saunders (:tbsaunde)]

(In reply to comment #6)
> Trevor, can you retest it against nightlies please, the way we create
> accessible tree is changed so since it looks like a timing issue then it might
> gone.

ok, tested against current nightly, still exists.

Comment 8

[alexander :surkov (:asurkov)]

(In reply to comment #7)

> ok, tested against current nightly, still exists.

Perhaps what you observe is a bug 634240 - no caret move events for any XUL textbox accessible, never, at least I can't reproduce this bug with a patch from that bug. Please try again when the patch is landed.

Comment 9

[alexander :surkov (:asurkov)]

worksforme per comment #8 (Trevor said on irc he can't reproduce it as well with bug 634240 fixed).