Closed Bug 16081 Opened 25 years ago Closed 24 years ago

no context menus on any form controls

Categories

(Core :: Layout: Form Controls, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: Brade, Assigned: law)

References

()

Details

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.
QA Contact: claudius → cpratt
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.
Summary: context menus come up when control-clicking on a <select> → context menus come up on any form controls
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).
Status: NEW → ASSIGNED
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)
OS: Mac System 8.5 → All
Hardware: Macintosh → All
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?).
Target Milestone: M14
Setting to M14, by which time we might figure out exactly what the problem is
and how to fix it?
Target Milestone: M14 → M15
Worry about this after beta 1 ...
QA Contact: cpratt → sairuh
spam: reassigning QA contact to self.
Summary: context menus come up on any form controls → no context menus on any form controls
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 ...
Target Milestone: M15 → M16
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. ***
Target Milestone: M16 → M18
Move to M21 target milestone.
Target Milestone: M18 → M21
*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.
QA Contact: sairuh → jrgm
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?
Blocks: 42438
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]
Component: XP Toolkit/Widgets → 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...
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
"copy" for listboxes -> bug 64468.
"select all" for multi-selects -> bug 65417.
verified build 2001081303 & 2001081308 os:winNT,linux7.1,mac8.6,win95
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.