go to bugzilla in apprunner press control key and then click in one of the <select> lists (to add or remove an item from the selection) Note that the selection is properly changed in the list but that the context menu also pops up. Context menu should not popup in this situation.

This foregrounds an xplat problem that I'm not sure anyone has thought of yet: Ctrl+click is what's used for acontinguous selections in select multiple lists - but Ctrl+click is the Mac OS standard for showing the contextual menu! CC'ing shuang in hopes of getting feedback from the UI/UE folks.

There are several Macintosh problems here (not sure if bugs exist for all of these): * in 4.61 on Macintosh, context menus are not brought up in form controls. * in 4.61 on Macintosh, control-clicking in form controls behaves the same as just clicking on form controls. * Standard UI on Macintosh is for Command-Clicking to handle discontiguous selection (not Control-Clicking). On Solaris 4.61, you can't bring up context menus in any of the form controls either. Shuang and team--should we stick to that behavior (not allow context menus)? Of course, we may have some issues with respect to ender. I think this bug should cover the issues regarding context menus in form controls. I will file a separate bug for Macintosh since Control-Click should not be used for discontiguous selection (should be Command-Click).

I'm confused by the references to 4.61. I'd really like to assign this to somebody who's in a better position to do something about it. Any suggestions or volunteers?

Ignore the references to 4.61 above if you like (that's fine). I believe that the bug here is that context menus should not come up in form controls. (there is another side issue that control-clicking in a form control is bad for Mac users but there is already another bug filed for that)

btw, I don't think this is a platform-specific bug so I am resetting the platform and OS. (I say this because I also checked the functionality on Solaris for Communicator 4.x)

What's wrong with context menu on form controls? Do you mean *all* form controls? What if I had an image on a button? I might want to view/save that image, no? I realize that the context-menu summoning might conflict with form interaction (but that's what the other Mac-specific bug is about?).

Setting to M14, by which time we might figure out exactly what the problem is and how to fix it?

Worry about this after beta 1 ...

spam: reassigning QA contact to self.

elig is now complaining that he doesn't get *any* context menu for form controls. Obviously the bahavior is still wrong. I'm just updating the summary so it better reflects today's state of affairs.

Move to M16 for now ...

Update: It seems that <input type="text"/> controls do allow you to get a context menu, but only once. After the form element is focused, you can no longer get a context menu for it. Just a bit of trivia to add.

*** Bug 32141 has been marked as a duplicate of this bug. ***

Move to M21 target milestone.

*spam*: transferring current XP Menu bugs over to jrgm, the new component owner. feel free to add me to the cc list (unless am the Reporter) of any of these, if you have any questions/etc.

Suggested menus ... * For text fields: _Undo ----------- Cu_t _Copy _Paste Select _All * For Navigator's location bar (special case of text field): _Undo --------------------------- Cu_t _Copy _Paste Select _All --------------------------- _Go to Address in Clipboard * For popup menus and listboxes: _Copy [copies contents of selected item(s) to clipboard] * For radio buttons and check boxes: no context menu * For buttons (HTML only): the same context menu as if the button was an ordinary link (see also bug 17754) -- including image-specific items, if the button is an image * For trees: as for text fields, with tree-specific items (e.g. `New Bookmark ...') tacked on the end after a separator (as for the context menu for the location bar above).

Is this bug covering all form elements, or just HTML ones?

This is only for html form controls in the browser area.

I'd like to keep this one specific to html form controls because the technique for dealing with those is is different than for xul widgets.

for those looking for the context menu in Navigator's location bar bug it is bug 43936

[Per Law's comment, changing component to HTML Form Controls]

what part of this still needs work?

What form controls still don't have context menus that need them, and on what platforms? Every HTML widget seems to have a context menu on Windows.

It seems that form elements get the standard Navigator context menu (by virtue of being in the content area). I'm not sure that there shouldn't be form-control-specific context menus, though. That's certainly what mpt proposes in this bug. There may also still be issues on Mac (where the context-menu-summoning was ambinguous).

OK. I can take this if you're busy.

When widgets go XBL, this might get solved along with it. However, I do not believe text widgets are in the list of widgets to XBLify... Hyatt?

There isn't much to solve here unless there are mac issues. The widgets have context menus, it's just a matter of what items need to be shown and hidden in each of them...

Mac issues? What Mac issues? There are no Mac issues. See Brade's 1999-10-12 comment. Whether it's a good idea to wait until HTML controls are XBLified depends on how long it will take to do that. What's the bug number for that? A small correction to my previous spec: you want to permanently disable (but not remove) `Cut' and `Paste' in the context menu for HTML list boxes. `Copy' should copy the text of the focused item in the list box, and `Select All' should select all the items in the list box.

This bug has morphed from "there shouldn't be context menus for form controls" to "all form controls should have context menus", and many context menus have been added since that change. It looks it's time to file bugs for the remaining issues and resolve this bug as wfm or invalid. mpt, do you want to do that, or should I? Looking at mpt's 06-22 suggestions, I see: - "copy" for normal selects - "select all" for multi-selects - "copy" for pop-up (mac) / drop-down (windows) selects (would this require menus on top of menus, like bug 50504 (context menus in bookmarks menu)?) - various things for buttons to make them act more like links - "go to address in clipboard" for location bar (see also bug 61057, for "go to address in location bar") - checkboxes/radiobuttons shouldn't have context menus (I disagree)

Yes, this has morphed far too many times. Look at the original bug. It's time for new bugs...

"copy" for listboxes -> bug 64468.

"select all" for multi-selects -> bug 65417.

verified build 2001081303 & 2001081308 os:winNT,linux7.1,mac8.6,win95