Closed Bug 691580 Opened 13 years ago Closed 7 years ago

Intermittent accessible/events/test_focus_contextmenu.xul | test with ID = ' 'item2.1' 'escape ' key' failed. There is unexpected focus event.

Categories

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

Product:
Core
Component:
Disability Access APIs
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: jwir3, Assigned: surkov)

References

(Blocks 1 open bug)

Details

(Keywords: intermittent-failure, Whiteboard: [part of test disabled][leave open])

https://tbpl.mozilla.org/php/getParsedLog.php?id=6660337&full=1 3116 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/a11y/accessible/events/test_focus_contextmenu.xul | test with ID = ' 'item2.1' 'escape ' key' failed. There is unexpected focus event.
Blocks: 438871
Whiteboard: [orange]
Note that this test was just checked in a few days ago, in bug 673958.
Blocks: 673958
OS: Linux → Windows XP
Hardware: x86_64 → x86
Blocks: a11yrandomorange
Summary: Intermittent TEST-UNEXPECTED-FAIL | chrome://mochitests/content/a11y/accessible/events/test_focus_contextmenu.xul → Intermittent TEST-UNEXPECTED-FAIL | chrome://mochitests/content/a11y/accessible/events/test_focus_contextmenu.xul | test with ID = ' 'item2.1' 'escape ' key' failed. There is unexpected focus event.
Assignee: nobody → surkov.alexander
Disabled item2.1 (and item2, which starts to fail the same way once 2.1 is disabled) on Windows in https://hg.mozilla.org/integration/mozilla-inbound/rev/97f93e053b4e so you'll be able to hear yourself think if you think about fixing it.
Whiteboard: [orange] → [orange][leave open]
(In reply to Ryan VanderMeulen from comment #322) > https://hg.mozilla.org/mozilla-central/rev/a713d74f4cd2 I enabled logging for a wrong test (In reply to Phil Ringnalda (:philor) from comment #346) > Disabled item2.1 (and item2, which starts to fail the same way once 2.1 is > disabled) on Windows in > https://hg.mozilla.org/integration/mozilla-inbound/rev/97f93e053b4e so > you'll be able to hear yourself think if you think about fixing it. backing it out to enable logging (sorry to keep you spammed again)
(In reply to alexander :surkov from comment #353) > backing it out to enable logging (sorry to keep you spammed again) http://hg.mozilla.org/integration/mozilla-inbound/rev/a8489b92ad02 http://hg.mozilla.org/integration/mozilla-inbound/rev/374c3d445fbc
Similar to my request in bug 708927: This is currently the number 5 toporange as of the last few days. Please can we disable the test on trunk for now; and try out a fix on Try first?
todo(false, "synthEscapeKey for item2.1 and item2 disabled due to bug 691580"); https://hg.mozilla.org/integration/mozilla-inbound/rev/e692911f891b
Summary: Intermittent TEST-UNEXPECTED-FAIL | chrome://mochitests/content/a11y/accessible/events/test_focus_contextmenu.xul | test with ID = ' 'item2.1' 'escape ' key' failed. There is unexpected focus event. → Intermittent accessible/events/test_focus_contextmenu.xul | test with ID = ' 'item2.1' 'escape ' key' failed. There is unexpected focus event.
Whiteboard: [orange][leave open] → [orange][part of test disabled][leave open]
log extract: registered: event type: focus, target: 'item2' registered unexpected: event type: focus, target: any target different from expected events Event queue: invoke: 'item2.1' 'escape ' key 4245 INFO TEST-INFO | chrome://mochitests/content/a11y/accessible/events/test_focus_contextmenu.xul | Invoke the ' 'item2.1' 'escape ' key' test { expected 'focus' event; unexpected 'focus' event; } sync notification processing A11Y FOCUS: active item changed; 51:04.516 { Item: 00000000; } { A11y target: 10AA0508; role: pushbutton, name: 'button'; A11y target node: 0C2078B8, button@id='button', idx in parent: 0 Document: 108595C8, document node: 0C91AD18 Documenturi: chrome://mochitests/content/a11y/accessible/events/test_focus_contextmenu.xul } { Caused by: popuphiding Item: 10C9E178; role: menupopup, name: 'item2'; Item node: 0C615BE8, menupopup@id='', idx in parent: 0 Document: 108595C8, document node: 0C91AD18 Documenturi: chrome://mochitests/content/a11y/accessible/events/test_focus_contextmenu.xul } A11Y FOCUS: fire focus event; 51:04.532 { Target: 10AA0508; role: pushbutton, name: 'button'; Target node: 0C2078B8, button@id='button', idx in parent: 0 Document: 108595C8, document node: 0C91AD18 Documenturi: chrome://mochitests/content/a11y/accessible/events/test_focus_contextmenu.xul } Event type: focus. Target: ['button@id="button" node', address: 0xc2078b8, role: pushbutton, name: 'button', address: 0x10aa0508]. Listeners count: 1 sync notification processing sync notification processing Event type: menupopup end. Target: ['menupopup node', address: 0xc615be8, role: menupopup, name: 'item2', address: 0x10c9e178] sync notification processing A11Y FOCUS: active item changed; 51:04.547 { Item: 108BCCC0; role: parent menuitem, name: 'item2'; Item node: 0C2C5770, menu@id='item2', idx in parent: 1 Document: 108595C8, document node: 0C91AD18 Documenturi: chrome://mochitests/content/a11y/accessible/events/test_focus_contextmenu.xul } { Widget: 0CA863B0; role: menupopup, name: ''; Widget node: 0CBFEC00, menupopup@id='contextmenu', idx in parent: 1 Document: 108595C8, document node: 0C91AD18 Documenturi: chrome://mochitests/content/a11y/accessible/events/test_focus_contextmenu.xul Widget is active: true, has operable items: true } { A11y target: 108BCCC0; role: parent menuitem, name: 'item2'; A11y target node: 0C2C5770, menu@id='item2', idx in parent: 1 Document: 108595C8, document node: 0C91AD18 Documenturi: chrome://mochitests/content/a11y/accessible/events/test_focus_contextmenu.xul } { Caused by: DOMMenuItemActive Item: 108BCCC0; role: parent menuitem, name: 'item2'; Item node: 0C2C5770, menu@id='item2', idx in parent: 1 Document: 108595C8, document node: 0C91AD18 Documenturi: chrome://mochitests/content/a11y/accessible/events/test_focus_contextmenu.xul } A11Y FOCUS: fire focus event; 51:04.594 { Target: 108BCCC0; role: parent menuitem, name: 'item2'; Target node: 0C2C5770, menu@id='item2', idx in parent: 1 Document: 108595C8, document node: 0C91AD18 Documenturi: chrome://mochitests/content/a11y/accessible/events/test_focus_contextmenu.xul } Event type: focus. Target: ['menu@id="item2" node', address: 0xc2c5770, role: parent menuitem, name: 'item2', address: 0x108bccc0]. Listeners count: 1 ***** EQ matched: focus *****
I'm pretty sure that popuphiding and DOMMenuItemActive are delivered not in sync and thus they aren't coalesced. That makes us to return a focus to the button for a short period.
Enn, do you have ideas why it can happen (comment #452)?
The popuphiding event will fire synchronously when the escape is pressed but the DOMMenuItemActive event will fire asynchronously. Is there some other event being handled in between? I can't tell from the log above.
We use popophiding event to fire accessible focus when menu is closed (i.e. the user gets back to the document). DOMMenuItemActive event is used for accessible focus too to report the user navigates the menu item. If these events happens asynchronously relatively each other then we get back the accessible focus into the document for a short time and it's unwanted by screen readers. Thus we need to have popuphiding and DOMMenuItemActive events or their alternatives in sync. Is the DOMMenuItemActive event fired asynchronously or menu item is activated asynchronously? I wonder if I replace DOMMenuItemActive event on direct call into a11y then would it work?
(In reply to alexander :surkov from comment #458) > Thus we need to have popuphiding and DOMMenuItemActive events or their > alternatives in sync. It can't, because it isn't safe to fire events at the point in the code when the menuitem is made active. Is the DOMMenuItemActive event fired asynchronously or > menu item is activated asynchronously? The former. > I wonder if I replace DOMMenuItemActive event on direct call into a11y then would it work? That would be a better idea in general. As long as the responder doesn't perform any unsafe calls (js, events, attribute setting, etc)
(In reply to Neil Deakin from comment #459) > > I wonder if I replace DOMMenuItemActive event on direct call into a11y then would it work? > > That would be a better idea in general. Can you point me a code I should patch please? > As long as the responder doesn't > perform any unsafe calls (js, events, attribute setting, etc) It will be used to fire accessible event which is delivered async. Thus it's safe.
There are two places where the DOMMenuItemActive event is currently fired, both by creating a nsMenuActivateEvent type. The first is in nsMenuFrame::SelectMenu which happens when a menuitem is selected/highlighted. The second is in nsMenuFrame::PopupClosed which happens when a popup is closed. The easiest way to check this one is to open a submenu, and then press Left. The DOMMenuItemActive event is fired on the parent menu.
(In reply to Neil Deakin from comment #461) > The second is in nsMenuFrame::PopupClosed which happens when a popup is > closed. The easiest way to check this one is to open a submenu, and then > press Left. The DOMMenuItemActive event is fired on the parent menu. does popuphiding event correlate to nsMenuFrame::PopupClosed? In other words is popuphidding event fired whenever nsMenuFrame::PopupClosed is called and if yes then are they other places where popuphidding event is fired?
nsMenuFrame::PopupClosed is called for the parent <menu> when its submenu is closed. Note that the popuphiding event doesn't indicate that a popup is guaranteed to close, as the event may be cancelled, so you shouldn't be relying on it as a means of ensuring that a popup is closed. Are you actually referring to the popuphidden event? What situation is it you're actually trying to detect?
(In reply to Neil Deakin from comment #463) > nsMenuFrame::PopupClosed is called for the parent <menu> when its submenu is > closed. Does it work as well for top level menus (like 'File' menu) when their popup are closed? > Note that the popuphiding event doesn't indicate that a popup is guaranteed > to close, as the event may be cancelled, so you shouldn't be relying on it > as a means of ensuring that a popup is closed. Are you actually referring to > the popuphidden event? I think we listen popuphiding because popup accessible still exists at this point. I agree we need to switch somehow to popuphidden. > What situation is it you're actually trying to detect? I gave some details in comment #458. Basically we use combination of popuphidding and DOMMenuItemActive events to manage accessible focus. DOMMenuItemActive makes us to fire a11y focus on active menuitem popuphidding makes us to return a11y focus to document more complicated combinations are used for different widgets (like autocompletes where we listen additionally DOMMenuItemInActive). In general I'd like to replace DOM events on direct calls into a11y so I try to figure out how to replace popuphidding + DOMMenuitemActive for menus and possible affect on other widgets. At least it seems I can add hooks into 1) nsMenuFrame::PopupClosed instead popuphidding 2) nsMenuFrame::SelectMenu and nsMenuFrame::PopupClosed instead DOMMenuItemActive (btw, is there specific reason why nsMenuFrame::SelectMenu isn't called on parent when nsMenuFrame::PopupClosed triggers). And it should be working for menus. I guess it's not for things like comboboxes and autocompletes.
I suspect what you actually want are to keep track of three different scenarios: - a menu has been made active. This can happen when a menu first appears or can happen when a submenu closes and its parent is made active. - a menu has been made inactive and something not in a menu is now focused. - the active item in the active menu has changed I wonder whether it would be better to simply invoke an accessible callback from nsXULPopupManager::UpdateKeyboardListeners (or SetCaptureState) or thereabouts.
Whiteboard: [orange][part of test disabled][leave open] → [part of test disabled][leave open]
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
the test is enabled https://dxr.mozilla.org/mozilla-central/source/accessible/tests/mochitest/events/a11y.ini#32, closing as wfm
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.