When opening a menu under linux, EVENT_MENU_START is fired, and then EVENT_FOCUS for the menu item, but EVENT_MENUPOPUP_START is missing. Test at events/test_menu.xul are disabled for linux because of this

That is because we are not creating accessible for XULMenupopup under linux. From nsAccessibilityService::CreateAccessibleByType: [...] case nsIAccessibleProvider::XULMenupopup: { #ifdef MOZ_ACCESSIBILITY_ATK // ATK considers this node to be redundant when within menubars, and it makes menu // navigation with assistive technologies more difficult // XXX In the future we will should this for consistency across the nsIAccessible // implementations on each platform for a consistent scripting environment, but // then strip out redundant accessibles in the nsAccessibleWrap class for each platform. nsIContent *parent = aContent->GetParent(); if (parent && parent->NodeInfo()->Equals(nsAccessibilityAtoms::menu, kNameSpaceID_XUL)) return nsnull; #endif accessible = new nsXULMenupopupAccessible(aContent, aWeakShell); break; }

as atk has not MENUPOPUP_START/END events and we are not adding a MENU_POPUP accessible (as gtk neither does) we can try to mimic gtk menus behaviour, that is: firing visible/showing state changes for all the items in the menu when it is shown. For that we need to handle native MENUPOPUP_START/END for ROLE_PARENT_MENUITEM and fire platform ATK_STATE_VISIBLE/ATK_STATE_SHOWING.

events/test_menu.xul still fails, because even if we get a menupopup event, the node type mismatch (node is menu instead o menupopup).

We shouldn't fire menupopup for menu. That's confusing. Perhaps we should have ifdef ATK processing when we handle those DOM events.

So in the our atk wrapper layer we could simulate the visible/showing state changes for the menu items? Feels hacky. I guess the other option is to somehow not coalesce these events for atk menus. Also feels a bit hacky. Alexander, what is your idea (comment 4)?

(In reply to comment #5) > Alexander, what is your idea (comment 4)? No suggestion in comment 4, just said what we shouldn't do. Since this bug doesn't look urgent then we could use the following long term approach here: 1) crossplatform accessible tree shouldn't depend on platform 2) platform accessible tree may vary (Mac approach) 3) when event is fired for non existing accessible in platform tree then 3.1) ignore it (like mutation events for text leaf accessilbles of text field) or 3.2) process to fire other events (like Fernando does)

When this is fixed, the tests turned off in bug 527646 should be turned back on.

> Mark Banner (:standard8) 2012-07-30 04:56:39 PDT > Blocks: 726770 > Mike Conley (:mconley) 2012-09-21 10:36:00 PDT > Depends on: 757394 Guys, when you add dependency please comment it. It's not really evident how bug 726770 and bug 757394 are related with this one.

Mike, you marked bug 757394 as blocking again. Can I know a reason?

(In reply to alexander :surkov from comment #10) > Mike, you marked bug 757394 as blocking again. Can I know a reason? Hey Alexander - yes, I asked you in Bug 757394 why you unblocked it. :) The reason I'm marking it blocking is because we're reasonably certain this bug is also causing our test failures in bug 757394. Once this bug is fixed, I believe we'll be able to close our bug and re-enable our tests - hence, it blocks us from that work. -Mike

(In reply to Mike Conley (:mconley) from comment #11) > (In reply to alexander :surkov from comment #10) > > Mike, you marked bug 757394 as blocking again. Can I know a reason? > > Hey Alexander - yes, I asked you in Bug 757394 why you unblocked it. :) Ok, I missed it since I guess I wasn't cc'ed there :) If you don't mind then we can keep discussion here > The reason I'm marking it blocking is because we're reasonably certain this > bug is also causing our test failures in bug 757394. Can I know the possible scenario how it happens. This bug is pure accessibility API bug, those tests don't look related with accessibility.

(In reply to alexander :surkov from comment #12) > > The reason I'm marking it blocking is because we're reasonably certain this > > bug is also causing our test failures in bug 757394. > > Can I know the possible scenario how it happens. This bug is pure > accessibility API bug, those tests don't look related with accessibility. Certainly. Testing interaction with menupopups, Mozmill synthesize's mouse click and mouseover events for various DOM elements, and listen for the menu events to be fired so that we know that the menu has appeared, and we can safely explore a submenu. We currently experience timeouts when opening some menus on Linux. We do not have those timeouts when we build with --disable-accessibility, so we're guessing that this bug is likely the cause. Cc'ing Hiro who can probably explain more, since he's the one who initially connected our test failures on bug 726770 with this bug.

(In reply to Mike Conley (:mconley) from comment #13) > We currently experience timeouts when opening some menus on Linux. We do not > have those timeouts when we build with --disable-accessibility, so we're > guessing that this bug is likely the cause. It should be something else. You don't rely on these events since your test work when accessibility is disabled. If we add them then I guess nothing should be changed for you. Anyway it'd be quite interesting to know how enabled accessibility affects on DOM events.

Having dug into this a bit, I'm less convinced that bug 757394 is involved with this one. Removing dependency. Sorry about that!

alexander :surkov, we have many test failures on linux because of popupmenus not appearing (or the proper state of the popupmenu not set). If this bug is not the reason, can you recommend any core/toolkit guys that could look into it?

For me --disable-accessibility does not fix the linux menu failures so you may be right.

(In reply to :aceman from comment #16) > alexander :surkov, we have many test failures on linux because of popupmenus > not appearing (or the proper state of the popupmenu not set). If this bug is > not the reason, can you recommend any core/toolkit guys that could look into > it? not sure, I would cc that test author and perhaps toolkit owner/peer asking them for advice.

Neil, can you recommend anyone for the linux menu problems? The bugs are e.g. bug 726770, bug 803604.

Is this still a problem with GTK3? Things may have changed.

I don't remember details about this

I'm not sure whether we have/had a linux problem at all, it might be rather Gecko internals thing, see comment #6. I'd say let's keep it open, until somebody get close to sort it out.