390698 - Extra MENUPOPUPEND event when using Dojo context menu

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Aaron Leventhal]

1. Load http://david.atrc.utoronto.ca/dijit/tests/test_Menu.html
2. In textfield type Shift+F10
3. MENUPOPUPEND event is mysteriously fired before MENUPOPUPSTART

Comment 1

[Aaron Leventhal]

Two problems:
First, I'd prefer that the node with the menu role be what's shown or hidden, but we might be able to deal with that.
Worse, Dojo is quickly showing, then hiding, then showing the div again.

Comment 2

[Aaron Leventhal]

Actually, here's roughly what's happening, but I need a better way to debug this:

1. <div> appended
2. <table> removed
3. <table> appended (same one from step 2)
4. div styled to invisible
5. A whole bunch of stuff inside the <table> gets styled to be invisible
6. A div gets styled to visible
7. A whole bunch of stuff inside the <table> gets styled to visible
8. A couple of divs get styled to visible

Something like that. I guess it's real world usage, but it's confusing why the table is removed then inserted like that.

Comment 3

[Aaron Leventhal]

Note for me -- also for some reason the events are coming out as event-from-user-input: false

Comment 4

[Aaron Leventhal]

Here's the correct series of events:
1. append <div> node 
2. remove <table> node 
3. re-append <table> node 
4. hide cells, text nodes, other sub-content of table
5. hide <table>, 6 times  (makes no sense that we were notified more than once)
6. hide <div>
7. re-show cells, text nodes, other sub-content of table
8. re-show <table>, 6 times  (makes no sense that we were notified more than once)
9. re-show <div>

Simon, does that make sense to you?

I suspect Dojo is doing more thrashing here that it needs to, although Firefox should probably learn how to deal with it.

However, you may want to look at whether Dojo is doing what it should here.

Comment 5

[Aaron Leventhal]

Maybe Dojo is doing:
1) Append div, 2) replace table, 3) hide div, 4) show div  ?

It seems to be #3 that's causing the extra menupopupend.

Comment 6

[Simon Bates]

I've done some investigating and here is what Dojo is doing:

1. creates a "wrapper" div [dijit.popup.open()]
2. appends the div to body [dijit.popup.open()]
3. changes the table style.display from "none" to "" [dijit.popup.open()]
4. appends the table to the div [dijit.popup.open()]
5. changes the div style.visibility from "" to "hidden" [dijit._place()]
6. changes the div style.visibility back to "" [dijit._place()]

dijit.popup.open() is in http://trac.dojotoolkit.org/browser/dijit/trunk/_base/popup.js

dijit._place() is in http://trac.dojotoolkit.org/browser/dijit/trunk/_base/place.js

Comment 7

[Simon Bates]

I've created a ticket on Dojo's trac to note the issue there: http://trac.dojotoolkit.org/ticket/4196

Comment 8

[Aaron Leventhal]

Why is the <div> wrapper needed?

It would help if the outer thing being made visible and hidden had role menu. Either:
- get rid of the extra div, or 
- put the menu role on the div and role=presentation on the table

That would help in the short term, but in the long term Mozilla probably needs to deal with weird stuff like this.

Comment 9

[Simon Bates]

It's not clear to me that the <div> wrapper is needed. I'll look into it.

Comment 10

[Aaron Leventhal]

Pleas keep the old version around too, it's a perfect stress test for our code.

We need to ensure perfectly symmetrical popupstart and popupend events on Windows, and this makes that quite difficult! :)

Comment 11

[Aaron Leventhal]

Attachment: Not working, posting because I need to take a break from this bug.

This solution was too brittle .... frustrating.

We need to keep track of an array of currently opened menupopups, and make sure that we only fire menupopupend events for them, and only once. We only need to look for menupopupend events when there are any open menupopups in that array.

Time to move on to another bug for now-- it's taking too long. We can revisit it later but I need to work on other bugs.

Simon, I recommend trying to fix this on the Dojo side for now.

Comment 12

[Marco Zehe (:MarcoZ)]

Aaron, please make sure that MENUPOPUPEND is sent *before* MENUEND events. Right now, Minefield sends them in the wrong order: First the MENUEND, then an OBJECT_FOCUS to the elemtnt that the context menu was created for, then a MENUPOPUPEND. This way, JAWS never recognizes that the menus have closed. So, the END events must follow in the reverse order the START events were fired, e. g. first a MENUSTART, then a MENUPOPUPSTART, has to be MENUPOPUPEND, then MENUEND.

Comment 13

[Simon Bates]

I've made a small Dojo patch that removes the extra MENUPOPUPEND:

http://trac.dojotoolkit.org/attachment/ticket/4196/hide_wrapper.diff

However, there are still extra events. The menu open is generating 7 MENUPOPUPSTARTs. To see the patch applied please visit:

http://sjb.atrc.utoronto.ca/dijit/tests/test_Menu.html

Comment 14

[Simon Bates]

I've committed the change to Dojo discussed in comment 13 above:

http://trac.dojotoolkit.org/changeset/10704

I've opened a new ticket for the 7 MENUPOPSTARTs:

http://trac.dojotoolkit.org/ticket/4616

Comment 15

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to comment #14)
> I've opened a new ticket for the 7 MENUPOPSTARTs:
> 
> http://trac.dojotoolkit.org/ticket/4616

Note: fixed in bug 413675

Comment 16

[David Bolter [:davidb] (NeedInfo me for attention)]

I think we've done all we are going to do on this bug. Good work happened on other bugs/tickets. Closing as WORKSFORME.