Closed Bug 130969 Opened 23 years ago Closed 23 years ago

Active Accessibility: extra focus event on content window after leaving URL bar for HTML control

Categories

(SeaMonkey :: General, defect, P2)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: dsirnapalli, Assigned: aaronlev)

Details

(Keywords: access, topembed+, Whiteboard: [adt2] - creates major problems for screen readers)

Attachments

(4 files, 1 obsolete file)

Dharma's example as an attachment
293 bytes, text/html
Details
example with focus event on select
422 bytes, text/html
Details
PresShell > ViewManager > Widget > ::SetFocus(). Now done before DOM event fired, to get order of accessibility focus events correct
4.24 KB, patch
bryner
: review+
hewitt
: superreview+
Details | Diff | Splinter Review
test results
5.47 KB, text/plain
Details
steps to reproduce: open the following html in mozilla. ----------------------- <html> <title> Select List </title> <body> <!-- Test Select List --> <u><b>Testing Select List</b></u> <br><br> Choose your favorite color <select> <option> Red </option> <option> Blue </option> <option> Green </option> <option> Yellow </option> </select> </body> </html> ------------------------- open mozInspect and click on "Show highlight rectangle" button. move the cursor into the url bar. now press the tab, now the higlight will be on panel, agian press tab, the select combobox should get the highlight but its not getting. sometimes it gets the highlight but its only waiting may be 1 sec or so.
QA Contact: doronr → dsirnapalli
Dharma, * I noticed that the yellow Inspect rectangle sometimes flashes very briefly on the pull down, and then onto the document. Dharma, do you see that? * I wonder if the DOM focus events are the culprit. Dharma, an you listen for DOM focus events and see if you're getting the right ones? If you're not, then this isn't just an Active Accessibility bug, it's a focus/event system bug.
Aaron, Yes, i noticed that the yellow Inspect rectangle sometimes flashes very briefly on the pull down, and then onto the document. I attached a small test case with focus event written on select. I feel focus event is getting fired. Mozilla hangs only when i go trough url bar to the select combo box and that too it hangs second time. I checked the following way. 1.Run the test case from mozilla or mozinspect. 2.open the inspect and click on "show highlight rectangel" 3.click the cursor on url bar and tab. It is able to tab to select combobox. you get the alert "here". 4.click the url bar again. 5.tab to select combo box. you will not be able to reach there. mozilla hangs. But when you do this way it works fine. 1.Run the test case from mozilla or mozinspect. 2.open the inspect and click on "show highlight rectangel" 3.click on the text "Testing select combobox". 4.now tab it goes to select combo box and event fires. 5.now click again on text ""Testing select combobox". 6.now tab it goes to select combo box and event fires. so as long as you are in the document it works fine, but when you go out of document and tab it does not get focus.
-- Make sure your cursor is in the url bar when you click on url bar.(not just focusing the rectangle on it). when you just focus on the url bar and tab it works fine.(how many ever times you do).
Okay, we've figured out what's going on here. There are 2 windows for the content, an outer one with the scroll bars, and an inner one without the scroll bars. This is true even if the scroll bars aren't visible, because the document is short. When you tab into a document, it calls nsEventStateManager::TabIntoDocument, and eventually focuses on the outer window. When you then tab to a content item, it calls nsEventStateManager::SendFocusBlur, which thinks the window that should be focused is the inner window. It then focuses the inner window, which ends up generating an extra MSAA focus event.
Assignee: jgaunt → aaronl
Keywords: access, nsbeta1, sec508
Priority: -- → P2
Summary: Active Accessibility: Html Select Combobox does not get focus when tabbed to it from url bar. → Active Accessibility: extra focus event on content window after leaving URL bar for HTML control
Target Milestone: --- → mozilla1.0
Status: NEW → ASSIGNED
Keywords: topembed+
This fixes 4 things. - Gets rid of extra MSAA focus events - Makes window focus that occurs as a result of tabbing the same as window focus that occurs as a result of clicking - Gets rid of some garbage MSAA window focus events that reported an old window - Fixes the order of MSAA focus events, so that the window focus shows before the specific control's focus event
Bryner, saari - I'm interested in getting your feedback on the methodology used in this fix, before pursuing testing.
Comment on attachment 76277 [details] [diff] [review] PresShell > ViewManager > Widget > ::SetFocus(). Now done before DOM event fired, to get order of accessibility focus events correct r=bryner
Attachment #76277 - Flags: review+
i've got results from test builds from aaronl (win2k), jgaunt (linux) and saari (mac) at http://hopey.mcom.com/tests/aaronl-27mar2002.txt i found a crash on mac when caret browsing was on and had opened a url in a new tab --details in that report (will attach soon).
Whiteboard: [adt2] - creates major problems for screen readers
Comment on attachment 76277 [details] [diff] [review] PresShell > ViewManager > Widget > ::SetFocus(). Now done before DOM event fired, to get order of accessibility focus events correct doesn't seem to break anything... r=saari
Comment on attachment 76277 [details] [diff] [review] PresShell > ViewManager > Widget > ::SetFocus(). Now done before DOM event fired, to get order of accessibility focus events correct sr=hewitt
Attachment #76277 - Flags: superreview+
checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
This fix broke focus on OS/2. When we go to www.google.com, the entryfield visually has focus (cursor is blinking) but you can't type in it until you click on it. Does anyone know if this broke anyone else?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Argh, sorry - I don't have any OS/2 machines to build on. I tested it on Win, Mac and Unix but obviously that was not enough. If you back this patch out on your machine that fixes it?
yeah, I verified that when I backed it out it fixed it on OS/2 Did you test this case specifically on Unix and Mac - going to www.google.com and then after it loads, start typing? I know this works on Windows, but I am wondering about others. I don't see why this would break OS/2 specifically. I could see why windows would work since it is the only platform that actually had the accessible API.
John, can you test this on Linux for me?
I;m taking this opportunity to rewrite our focus code. After my first pass, www.google.com is working. So I'll handle the focus rewrite in bug 145561
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
-- Verified in todays trunk build. Works fine. Marking bug as verified.
Status: RESOLVED → VERIFIED
the patch here also fixed crash/hang bug 116206 on the trunk.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: