Extra MENUPOPUPEND event when using Dojo context menu

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
12 years ago
10 years ago

People

(Reporter: aaronlev, Assigned: davidb)

Tracking

(Blocks 1 bug, {access})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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
Blocks: aria
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.
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.
Note for me -- also for some reason the events are coming out as event-from-user-input: false
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.

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.
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
I've created a ticket on Dojo's trac to note the issue there: http://trac.dojotoolkit.org/ticket/4196
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.
It's not clear to me that the <div> wrapper is needed. I'll look into it.
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! :)
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.
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.
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
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
(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
I think we've done all we are going to do on this bug. Good work happened on other bugs/tickets. Closing as WORKSFORME.
Assignee: aaronleventhal → david.bolter
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.