Community
Participate
Working Groups
we put anchor tags in dojo menus to get link behavior. One problem with this is that you have to actually hit the link, you can't sloppily click on the edge of the menu item. Yet the menu hover leads you to believe that you can. I wonder if there's something simple we can do to have the regular menu behavior we are currently overriding do something like fake an event to invoke the link. I'll bet fixing this would also fix bug 369469. I'd like to look at it in RC2 and assess risk. It seems much more prominent now that the user menu has these links.
*** Bug 375000 has been marked as a duplicate of this bug. ***
do this after we are on dojo 1.7
moving out of 0.5M2 to 0.5 milestone until we have more specific buckets for future
I played around with simulating an anchor event when the dijit menu item is clicked. It worked great on Chrome (gave you the right click, ctrl+click behavior on the menu item in addition to the link) but in FF the ctrl augmented clicks were ignored, and in IE, all clicks in the menu item behaved as if you had clicked without ctrl. These differences made the fix "not worth it" but I wanted to record the technique here for future playing around, becuase it seemed promising. On click of the menu, get the anchor and spoof an event: var anchor = dojo.query("a", this.domNode)[0]; //$NON-NLS-0$ if (anchor && anchor !== evt.target) { // if the menu item, but not the anchor, is clicked simulate a click event on the anchor. // We can't dispatch the existing event because dispatching an event already in the tree // will throw DISPATCH_REQUEST_ERR : Number = 1 // So we create an identical event. var clickEvent = window.document.createEvent("MouseEvent"); //$NON-NLS-0$ clickEvent.initMouseEvent("click", evt.bubbles, evt.cancelable, window, evt.detail, //$NON-NLS-0$ evt.screenX, evt.screenY, evt.clientX, evt.clientY, evt.ctrlKey, evt.altKey, evt.shiftKey, evt.metaKey, evt.button, anchor); anchor.dispatchEvent(clickEvent);
"Fixed" in http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=c9db0235f31af3150ab3c14f5fa96d86dcd0f239 A gentler fix than described above is to style in some padding to the right of all menu links so that you can more easily "hit" the link as you move your mouse down the menu. I would have liked to have used a min-width so that the hit area was the same for all menu items, but this did not work given the implementation of menu as a table. So I added some padding to the right of all link menu items. This particularly helps in the user menu, where the links have short names and the menu is wider to accomodate "Keyboard Help". While experimenting with all this, I noticed that the user menu/related pages coded their own ctrl/key behavior which woudl include having bug 350584, etc. I converted the menuitems to use CommandMenuItem. So all of our "links in menus" will behave the same way and any further improvements will work for all... Marking fixed even though this is not truly fixed, but after talking with Simon and Ken, it seemed better to do the gentle fix than make life worse on IE.
