Closed Bug 54149 Opened 24 years ago Closed 22 years ago

Context menu for HTML form input elements needs simplifying

Categories

(SeaMonkey :: General, defect, P3)

Product:
SeaMonkey
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jruderman, Assigned: bugzilla)

References

(Depends on 1 open bug,
URL
)

Details

There should be a separator between the form-filling commands and the edit 
commands on the context menu for the content area.  Currently, the two sets of 
commands are lumped together in a confusing way.

Also, I think the form-filling commands should be moved above the edit commands 
on the context menu so that the edit commands are closer to being "in a 
constant spot" on the menu for pages that do and do not have prefillable forms.
Oooo. This sucks. Timeless?

Currently we have:

  Back
  Forward
  Reload
  Stop
----------------------
  View Page Source
----------------------
  Bookmark This Page
----------------------
  Save Page As ...
----------------------
  Select All
  Cut
  Copy
  Paste
  Save Form Data
  Prefill Form

What we should have, for HTML text fields, is something like this instead:

  Undo
----------------
  Cut
  Copy
  Paste
  Delete
----------------
  Select All
----------------
  Save Form
  Fill In Form
OS: Windows 98 → All
Hardware: PC → All
This is not minor, but there are a few separate issues here.
bug 43936 might be helpful.

mpt, in nc4.75 on w2k I have:
Undo
-
Cut
Copy
Paste
Delete
-
Select All
-
Right to Left Reading order
Show Unicode control characters
Insert Unicode control character> [popup whose content i cannot remember]

If we wanted to support bidi input (which we should when bidi lands) where 
would that go in the menu? [my guess is above the form stuff]

mkaply: would we support this?

For a document w/ a form, the context menu of the document is [as of 9/25-5]:
{for a link - covered in some other bug, but reproduced here because it's 
related}

{Open Link in New Window
Edit Link in Composer
-}
&Back
&Forward
&Reload
Stop                  -> &Stop        [nc4 uses S&top]
-
View Page Source      -> View S&ource
 [Page is obvious and not stated in nc4; presumably for this reason]
                      +> View &Info   [nc4 uses &View Info]
-
&Bookmark this Page {&Bookmark this Link}
-
&Save Page As...
{S&ave Link As...}
-
Se&lect All
&Copy
                       x> {Copy Li&nk Location}
                       +> -
Save Form Data         -> Save Form &Data
Prefill Form           -> Fill &Out Form
 [In wouldn't be a convenient accesskey]
{Copy Li&nk Location}  x> {}

mpt do you remember where the top link things where supposed to land?

And then if you really want to see something strange, right click a linked 
image on a page w/ a form (eg url)

highlights:
View Page Source
View Image                -> View &Image [not possible in current 
implementation]
Block Image from Loading
-
..
-
&Save Page As...
S&ave Link As...
S&ave Image As...
-
..
..
..
Prefill Form
Copy Li&nk Location
Copy I&mage Location

nc4's status bar tells you what each item does, which means the app has a 
chance of explaining its obscure text.  mozilla doesn't.

imo View Image should hint ~browse to this image~ [it's too hard to guess that 
View!=Show wrt not autoloading images]

Are we opposed to using cascading popup menus?

If not:

Back
Forward
Stop
Reload
-
Document>
 View Info
 View Source
 Add Bookmark
 Save As...
Link>               (only visible for links)
 Open in New Window
 Edit in Composer
 Add Bookmark
 Copy Location
 Save As...
Image>              (only visible for images)
 Browse to {text subject to mpt replacement}
 Block from Loading {ibid}
 View Info
 Copy Location
 Save As...
-
Save Form Data
Prefill Form

Access keys assigned logically

Forms would still get the menu mpt described (except my preference for Fill 
Out instead of Fill In).

Do Prefill and Capture work on the document or the form?
<html><body><form><input></form><form><input></form></body></html>

mpt, german, jglick: How many opinions and objections do you have ;-?
URL: http://tinderbox.mozilla.org/admintre...
Severity: minor → normal
Keywords: ui
There is going to be an additional menu under View I believe? (Same place a 
character coding) called Bidi Options.

It will allow you to switch the page from right to left, as well as other Bidi 
Options.

We did not put these options onto the context menu for the page.
Whoa there Timeless, let's keep this bug just to the context menu for text 

widgets, okay?



There is no problem at all if this menu is totally different from the context 

menus for the rest of the page (i.e. it doesn't have Back, Forward, etc) -- it's 

hardly ever going to happen that text elements to cover a page so thoroughly that 

it's difficult to get to a place where the normal page context menu is available.



> Are we opposed to using cascading popup menus?



Abso-fricking-lutely. It's a context menu, not a 747 cockpit. If I want submenus, 

I'll go somewhere where I can be reasonably sure of them popping up in the same 

direction each time -- like the main menu bar, for instance.



> Do Prefill and Capture work on the document or the form?



Currently the form items are present for the whole document, which looks like a 

bug (what if there is more than one form on the same page)?



So, my suggestion stays exactly the same -- with the mnemonics `&Save Form' and

`&Fill In Form'. Bi-di stuff should stay out of the context menu (and go in the 

`Edit' menu instead), for the same reason as `Redo' should: it won't be used 

often enough. And in this case, ease of mnemonics are not a good enough reason to 

change the actual wording of `Fill In Form'.



Obviously the lack of a global spec for context menus is rearing its ugly head 

again. I'll see if I can come up with something. :-)


> Whoa there Timeless, let's keep this bug just to the context menu for text 
> widgets, okay?

Is there a bug on the prefill form commands showing up on more context menus 
than they should?  I originally filed this bug with page context menus in mind, 
not text widget context menus.

Also, is there a bug on the problem timeless mentioned of Mozilla not using the 
status bar to explain what the context menu items do?
Sorry Jesse, by `the content area' I thought you meant text field contents. We'll 
use this bug for that, as it's the most urgent; please file a separate bug asking 
for the auto-fill form goop not to show up in non-form context menus.

Status bar tips for menu items is bug 47434.
Summary: context menu needs separator between 'prefill form' and edit commands → Context menu for HTML form input elements needs simplifying
I filed bug 54300 for needing a separator between the edit commands and the 
form-filling commands on the "normal" context menu for a webpage.
The discussion here overlaps a bit with the discussion in bug 36866.
Depends on: 47434
Blocks: 36866
Sending to German for comment.
Assignee: hangas → german
How's the comment on this coming along?
mass-moving UI:Design Feedback bugs to hangas
Assignee: german → hangas
Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
Depends on: 75338
No longer blocks: 36866
*** Bug 119804 has been marked as a duplicate of this bug. ***
-> me
Assignee: mpt → blaker
These are pretty simple now.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Component: User Interface Design → Browser-General
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.