no context menus on any form controls

VERIFIED FIXED

Status

()

Core
Layout: Form Controls
P3
normal
VERIFIED FIXED
19 years ago
17 years ago

People

(Reporter: Brade, Assigned: Bill Law)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
QA Contact: claudius → cpratt

Comment 1

19 years ago
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.
(Reporter)

Updated

19 years ago
Summary: context menus come up when control-clicking on a <select> → context menus come up on any form controls
(Reporter)

Comment 2

19 years ago
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).
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 3

19 years ago
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?
(Reporter)

Comment 4

19 years ago
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)
(Reporter)

Updated

19 years ago
OS: Mac System 8.5 → All
Hardware: Macintosh → All
(Reporter)

Comment 5

19 years ago
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)
(Assignee)

Comment 6

19 years ago
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?).
(Assignee)

Updated

19 years ago
Target Milestone: M14
(Assignee)

Comment 7

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

Updated

19 years ago
Target Milestone: M14 → M15

Comment 8

19 years ago
Worry about this after beta 1 ...
QA Contact: cpratt → sairuh
spam: reassigning QA contact to self.
(Assignee)

Updated

19 years ago
Summary: context menus come up on any form controls → no context menus on any form controls
(Assignee)

Comment 10

19 years ago
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.

Comment 11

19 years ago
Move to M16 for now ...
Target Milestone: M15 → M16
(Assignee)

Comment 12

18 years ago
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. ***

Updated

18 years ago
Target Milestone: M16 → M18

Comment 14

18 years ago
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

Comment 16

18 years ago
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).

Comment 17

18 years ago
Is this bug covering all form elements, or just HTML ones?
Blocks: 42438
(Reporter)

Comment 18

18 years ago
This is only for html form controls in the browser area.
(Assignee)

Comment 19

18 years ago
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.

Comment 20

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

Comment 21

18 years ago
[Per Law's comment, changing component to HTML Form Controls]
Component: XP Toolkit/Widgets → HTML Form Controls

Comment 22

18 years ago
what part of this still needs work?

Comment 23

18 years ago
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.
(Assignee)

Comment 24

18 years ago
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).

Comment 25

18 years ago
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?

Comment 27

18 years ago
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...

Comment 28

18 years ago
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.

Comment 29

18 years ago
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)

Comment 30

18 years ago
Yes, this has morphed far too many times.  Look at the original bug.  It's time 
for new bugs...
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 31

18 years ago
"copy" for listboxes -> bug 64468.

Comment 32

18 years ago
"select all" for multi-selects -> bug 65417.

Comment 33

17 years ago
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.