Closed Bug 448836 Opened 13 years ago Closed 10 years ago
Name entry of Add Bookmark dialog does not initially emit caret-moved events
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
This is a regression from bug 345759. See: http://hg.mozilla.org/mozilla-central/index.cgi/shortlog/fd6a651efed4
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.
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.
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.
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.
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.
Target Milestone: --- → mozilla2.0b10
(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.
(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.
Target Milestone: --- → mozilla2.0b11
worksforme per comment #8 (Trevor said on irc he can't reproduce it as well with bug 634240 fixed).
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.