391841 - Menu close events no longer fired

Status: RESOLVED DUPLICATE of bug 390589

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007081104 Minefield/3.0a8pre
Build Identifier: 3.0a8pre/gecko/2007081104

When opening Minefield, the About... dialog is no longer spoken by Orca when the Help/About Minefield... menu item is spoken. This worked fine in August 3rd nightly.

Reproducible: Always

Steps to Reproduce:
1. Start Minefield.
2. Go to Help, and arrow to About Minefield...
3. Press ENTER.

Actual Results:  
Orca remains silent, braille does not update.

Expected Results:  
Orca should speak the dialog with version information.

This worked OK in the nightly build of August 3, 2007.  I also see this behaviour occasionally in Thunderbird 3.0a1pre/2007081104. Does not happen on Windows.

Comment 1

[Aaron Leventhal]

Thanks for the bug.

There are no menu closed events on Linux, only on Windows. Yes you're saying it's only broken on Windows. So what's really going on here?

Is August 4 the first time it broke?

Comment 2

[Marco Zehe (:MarcoZ)]

(In reply to comment #1)
> There are no menu closed events on Linux, only on Windows. Yes you're saying
> it's only broken on Windows. So what's really going on here?

No, I said the problem does not happen on Windows, meaning on Windows the menus close and the dialog is spoken. On Linux using Orca 2.19.90 pre, latest revision from the SVN repository, the dialog does not get spoken.

> Is August 4 the first time it broke?

I didn't test that build. According to Joanmarie, we should hold off testing Firefox builds later than August 3, until bug 391023 is fixed. Since that has happened now, I updated from August 3 to August 11, and that's when I noticed that the behaviour had regressed. On the August 3 build of Minefield using the same Orca version, the dialog was spoken for me.

Comment 3

[Aaron Leventhal]

Sorry, I misspoke. I realize you're saying it's only roken on Linux.

But what doesn't make sense to me is the bit about menu close events. I don't know what that translates to in ATK.

If someone from the Orca team could tell me what we're doing differently that'd be great.

Comment 4

[Marco Zehe (:MarcoZ)]

Hi Aaron, forget that part about menu close events...I was under the assumption that these also exist on Linux. Since I'm fairly new to this platform, I was obviously in error on that part. :-)
Fact is that with the August 11 build, when pressing ENTER on the Help/About Minefield... menu item, the dialog no longer gets spoken automatically. With the August 3 build, this worked fine. I just re-confirmed this by rolling back my Minefield install to August 3.

Comment 5

[Marco Zehe (:MarcoZ)]

Additional information:
The problem starts happening between:
nightly/2007-08-03-04-trunk/firefox-3.0a7pre.en-US.linux-i686.tar.bz2
and
nightly/2007-08-03-08-trunk/firefox-3.0a8pre.en-US-linux-i686.tar.bz2
If I use the former, everything works as expected. If I use the latter, the problem as described occurs.

Comment 6

[Joanmarie Diggs]

> If someone from the Orca team could tell me what we're doing differently that'd
> be great.

I'm not entirely sure what it is, but it seems to somehow be related to the OK button.  Prior to the introduction of the bug the dialog appears, we get all expected events (including children-changed events related to the OK button).  Eventually we get the window:activate event for the dialog and start reading it.

Beginning with Gecko/2007080308 Minefield/3.0a8pre, when the dialog box appears, the OK button visually seems to have focus (new behavior).  Contrary to what the little dots around the OK button would suggest, the OK button does not have focus as evidenced by the fact that pressing space bar on it does nothing.  We do not get any events (children-changed or otherwise) related to the OK button.  Instead, things seem to basically stall out event-wize with the last event being a children-changed:add for the Credits button.  At this point if you press Escape, the OK button visually seems to lose focus (those little dots go away) and events resume.  We still don't get any events related to the OK button, but we do eventually get our window:activate event and start reading the contents of the dialog.

Hope this helps!

Comment 7

[Ginn Chen]

confirmed, regression between Aug 03 and Aug 04

window:activate event is missing since Aug 04 nightly build

Comment 8

[Ginn Chen]

regression of bug 388995

Comment 9

[Ginn Chen]

To test this bug without Orca or Accerciser

1) Go to Help, and arrow to About Minefield.. , press enter

2) About Minefield dialog popup, OK button looks focused
Press enter, nothing happened. (BUG)
Press enter again, nothing happened. (BUG)

3) Press escape, OK button looks not focused.

4) Press escape or enter, About Minefield dialog is gone.

If you set a breakpoint at nsMenuPopupFrame::HidePopup
after 1), you will get
nsMenuPopupFrame::HidePopup (this=0x8a03c54, aDeselectMenu=1, aNewState=ePopupInvisible) 
after 3), you will get
nsMenuPopupFrame::HidePopup (this=0x8a03c54, aDeselectMenu=0, aNewState=ePopupClosed)

I think it's the cause.

Comment 10

[Ginn Chen]

Well, it's not that easy.
I really don't think I understand the code now.

Looks like, we missed nsXULPopupManager::HidePopup when About dialog pops.
On earlier build, the stack is
#0  nsXULPopupManager::HidePopup (this=0x80bb398, aPopup=0x88643d0, aHideChain=0, aDeselectMenu=0, aAsynchronous=1) at nsXULPopupManager.cpp:473
#1  0xb572deb5 in nsMenuBarListener::ToggleMenuActiveState (this=0x89cfd08) at nsMenuBarListener.cpp:143
#2  0xb572df8f in nsMenuBarListener::Blur (this=0x89cfd08, aEvent=0x916bae0) at nsMenuBarListener.cpp:364
#3  0xb5819e03 in DispatchToInterface (aEvent=0x916bae0, aListener=0x89cfd0c, aMethod=<error reading variable>, aIID=@0xb5cdb9fc) at nsEventListenerManager.cpp:182

If I add HidePopup(mCurrentMenu->Frame()->GetContent(), PR_FALSE, PR_FALSE, PR_FALSE) at end of
nsXULPopupManager::ExecuteMenu, this bug is gone.
But I don't think it's the right fix.

Comment 11

[Neil Deakin]

Does the patch in bug 390589 fix this?

Comment 12

[Ginn Chen]

Yes, it does.