Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#16551 closed defect (fixed)

dijit/Menu fails to appear when right-clicking on dijit/Dialog with contextMenuForWindow set to true

Reported by: Jason Cowley Owned by: bill
Priority: undecided Milestone: 1.8.4
Component: Dijit Version: 1.8.3
Keywords: Cc:
Blocked By: Blocking:

Description

The contextMenuForWindow option on dijit.Menu does not work when right-clicking on a dijit.Dialog. The _onBlur handler in dijit._DialogBase is triggered on the right-click which sets the focus back to the dialog and hiding the menu.

Change History (18)

comment:1 Changed 7 years ago by bill

Milestone: tbd1.8.4
Status: newassigned

Yah, sorry about that, I broke it when fixing #15370. Almost a dup of #16550, although the contextMenuForWindow option is a twist.

comment:2 Changed 7 years ago by bill

Resolution: fixed
Status: assignedclosed

In [30290]:

Rollback [30001] and [30268], changes for restoring focus to Dialog when it's lost via a mouse click. Refs #15370 and fixes #16550 and #16551 on 1.6 branch, !strict.

comment:26 Changed 7 years ago by bill

In [30291]:

Rollback [30000] and [30269], changes for restoring focus to Dialog when it's lost via a mouse click. Refs #15370 and fixes #16550 and #16551 on 1.7 branch, !strict.

comment:27 Changed 7 years ago by bill

In [30292]:

Rollback [29999], changes for restoring focus to Dialog when it's lost via a mouse click. Refs #15370 and fixes #16550 and #16551 on 1.8 branch, !strict.

comment:28 Changed 7 years ago by bill

Actually, it's debatable what the right behavior is. Since the modal Dialog is supposed to block interaction with the underlying page, maybe it should be blocking the context menu from appearing too.

What is your context menu, and why were you expecting it to show up even when a Dialog was shown?

comment:29 Changed 7 years ago by Jason Cowley

We have a large single-page application that behaves for the most part like a desktop application. The majority of our users come from a Microsoft Excel background and are used to the way things work in that environment, so they expect the right-click context menu to provide actions that are relevant to the application, and to avoid confusion we override the browser's default menu. This is important as we had complaints from users prior to implementing the context menu. While I appreciate there may be workarounds, currently the whole mechanism relies on the oncontextmenu handling attached to the page and changing it is non-trivial.

However, the _onBlur handler in the dialog is actually causing an error in our application. I think it was because the menu was trying to set the selection on the first item in the menu after the menu had been hidden when the focus changed. I didn't get the same error when I tried to create a simple reproducible test case, which makes me think it might be a timing issue.

comment:30 Changed 7 years ago by bill

OK, but I'm asking specifically why you were expecting the context menu to show even when there's a Dialog shown.

For example, Chrome has a default context menu, but you can't access while the "save as" dialog is being shown.

comment:31 Changed 7 years ago by Jason Cowley

The application contains dialogs that are complex and not just simple Yes/No? or OK/Cancel type dialogs. They may contain our custom grid component for example which has functionality available on a right click. This is why we still want to suppress the browser's context menu and show our own custom one.

comment:32 Changed 7 years ago by bill

Sure, it makes perfect sense to setup context menus on things in the Dialog. It's just strange that you are using Menu's contextMenuForWindow flag.

comment:33 Changed 6 years ago by 15413

We use a dgrid in a dialog. And use contextmenu event to popup a menu. The menu has items such as "Add row", "Delete Row". It's very strange that you are using Menu's contextMenuForWindow flag. I think the dialog should not do any more works about the contextmenu.

Last edited 6 years ago by 15413 (previous) (diff)

comment:34 Changed 6 years ago by Jason Cowley

Having a context menu on a grid is not the only problem we were trying to solve. We want to control the context menu for the whole application. The grid may appear in a number of places it may appear in a dashboard, a module tab, the settings page or a dialog. In the case of a grid within a dashboard, the context menu aggregates the applicable menu items from the grid and from the dashboard and any application-wide options at the top-level.

I agree that this may be an uncommon use case, but it is what we have. However it feels wrong to me that the dialog takes the focus back when it gets an onBlur.

comment:35 Changed 6 years ago by 15413

Dialog has strange behavior.

Context menu hide -- 1.8.3.

Dijit/Tree?'s node can't be selected in a dialog -- 1.8.0.

comment:36 Changed 6 years ago by johan

This bug is causing me a lot of issues as well. I have several complex dialogs in my application - with datagrids and trees. Having context-menus on those is critical - right now I've had to hack the dojo-code to work around it :-(

Can you please reconsider fixing this for 1.9 ?

comment:37 Changed 6 years ago by bill

It's already fixed for 1.9, and 1.8.4.

comment:38 Changed 6 years ago by johan

Sorry... I somehow missed the status :) That's great news. Thanks !

comment:39 Changed 6 years ago by johan

I upgraded to 1.8.4RC1 and sure enough this problem is fixed - however I am now seeing a different problem. One of my dialogs opens up yet another dialog if the user wants to edit a certain value - when that happens now the entire background shifts up (in chrome it is very significant, in firefox a little less). Not sure if it is a regression from fixing this defect or of it is something unrelated - but this used to work fine.

comment:40 Changed 6 years ago by bill

You can another ticket if you want, but you'll need to be more specific and give a test case.

comment:41 in reply to:  39 Changed 6 years ago by Jason Cowley

Replying to johan:

I upgraded to 1.8.4RC1 and sure enough this problem is fixed - however I am now seeing a different problem. One of my dialogs opens up yet another dialog if the user wants to edit a certain value - when that happens now the entire background shifts up (in chrome it is very significant, in firefox a little less). Not sure if it is a regression from fixing this defect or of it is something unrelated - but this used to work fine.

I had the same problem with one of my dialogs that contained a dgrid. I was only seeing it in Chrome and IE9/10. I was setting the focus when the dialog was displayed, but in the end I think I fixed it by setting the focus in a setTimeout.

Note: See TracTickets for help on using tickets.