Missing Form commands from new context menus.

VERIFIED INVALID

Status

VERIFIED INVALID
17 years ago
10 years ago

People

(Reporter: jasonb, Assigned: bugzilla)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: WONTFIX?)

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+)
Gecko/20020405
BuildID:    2002040503

When right-clicking on a form, we no longer have available any of the Form
related commands - (Fill In Form / Save Form Info).  Granted these shouldn't
appear unless you're clicking on a form field - but if you are, they should be
there.  (I just noticed this today when doing some online banking.)

Reproducible: Always
Steps to Reproduce:
1. Go to a Web page with a form.
2. Right-click on a form field.
3. Observe that neither "Fill In Form" nor "Save Form Info" are available,
either as their own items or as part of a "Forms" sub-menu.

Actual Results:  Form commands are missing from new context menus.

Expected Results:  Form commands should be present when right-clicking on a form
field.  Currently, in order to get to them, you have to use Tool -> Form Manager
from the main menu.

Comment 1

17 years ago
qa --> sairuh@netscape.com
QA Contact: paw → sairuh
(Assignee)

Comment 2

17 years ago
This is by design. Access them from the Edit menu.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 3

17 years ago
Can you point me to the guidelines for the design specifications and their
rationale?  So far, everything about the menu redesign has, more or less, made
sense.  This doesn't.  In every other context I've had occasion to use I've seen
the menu options you'd expect there.  This one is conspicuously lacking.
(Assignee)

Comment 4

17 years ago
The form commands are not context-sensitive.
(Reporter)

Comment 5

17 years ago
Not any more, but they were in the pre 0404 builds.  Other bugs have been
reported with the context menus and have generated debate.  I find it odd that
this bug is shut down without any discussion.  Again, where are the
specification and rationales for the new context menus?

Comment 6

17 years ago
I have to agree with Jason; I do not understand why form commands are no longer
context sensitive by design.

Regarding the suggestion that we should use the menus, what about when there are
no menus accessible?  

Without further details and explanation, I can not see why this feature has been
removed from Mozilla.
(Reporter)

Comment 7

17 years ago
If nobody else agreed with me I would have left this closed.  Reopening due to
support.  Let's discuss this first.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
(Reporter)

Comment 8

17 years ago
I have some answers from the General forum on Mozillazine.  In the the context
menu clean-up discussion (bug 75338), a proposed UI for including  "Prefill" and
"Save Data" is introduced (bug 75338 comment 55).  There seems to be no further
discussion of these commands, and no argument against including them.  They are
simply dropped for no apparent reason.  I continue to question why this is "by
design".
These menu items have _never_ been context sensitive. Context sensitive means it
matters where you click.

The rationale was "these menus are too long and something needs to go". These
were the least-used items. They have gone.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → WONTFIX
Whiteboard: INVALID?

Comment 10

17 years ago
Ok, I can see that it was not context sensitive.

However, the issue as stated in the summary is still an issue.

Previously it was possible to right click and choose to save form data or
prefill a form.  That functionality has now been taken away.

Scenario : If you are presented a form and Menus are not accessible, how do you
prefill the form or save the form data?  

Unless some other means is provided, I recommend that these 2 items be returned
to the context menu from which they were removed.

Personally I never had a problem with the length of the context menus and I use
these 2 form commands much more frequently than some of the other items that are
in the current context menu.

Please reopen this bug.
(Assignee)

Comment 11

17 years ago
How do you change the text zoom without menus? How do you view your preferences?
Not having menus accessible is not a common scenario.
(Reporter)

Comment 12

17 years ago
Ian: These commands may not have been "context sensitive", in the sense that
they only appeared at certain times during a right-click, but the *DID* appear
on the "context menus" that came up whenever you did do a right click.

The right-click functionality that was there before is now gone.  Being able to
right-click and get "Prefill Form" or "Save Form Data" was very useful.  I don't
see what negative impact would be generated by having a "Form" sub-menu in those
cases when you right-click on a menu field; I can only see a postitive impact here.

In the sense that these items ALWAYS appeared when right-clicking, I can
understand why removing them made sense.  However, I'm not asking for them to
always appear, and I'm only asking for the addition of one more item (a
sub-menu) only when right-clicking on a form field and at no other time.

Blake: The fact that the commands are available in the menus is not sufficient
reason to remove them from a context menu.  If that WERE sufficient reason, we
would have no context menus at all - because everything is available via the menus.

The number of items when right-clicking in a form field is now *LESS* than the
number of items when right-clicking in other areas of the browser.  Those
context  menus are considered to have an acceptable number of items - more than
those in form context menus.  If you're going by a "maximum" item number,
putting the Form commands back into the Form context menus would still be below
that limit.

Let me try this one more time.  If, after a day, nobody other than Mark has
commented in favour of having this I'll concede and close the bug myself.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
(Assignee)

Comment 13

17 years ago
Having the items available only when right clicking on a form element would give
the mistaken impression that the items are context-sensitive, which they are not.

The real problem here is that they're *not* context-sensitive.  The real, *real*
problem is that our form filling features are terrible.  They shouldn't require
any menu items, main or context; look at IE.

Sorry, but you're never going to convince me :-)
(Assignee)

Comment 14

17 years ago
By the way, "because everything is available via the menus." is not true at all.
 Tons of stuff are only available in the context menu because they are so
context dependent that putting them in the main menu wouldn't make sense (you'd
have to focus the content first, which is difficult).  Stuff like "Open Link in
New [Tab|Window]," "View Image," and so forth are only available in the context
menus.

Comment 15

17 years ago
Although I do not see why it is relevant, FYI :

Text zoom is easily accessible using keyboard shortcuts.

I do not know of any way to access Preferences without the menus.  If you want
that functionality, feel free to file a bug.


Neither one of the above examples though has any corelation to this bug.

The situation here is that functionality has been taken away without warning or
explanation.  Now the explanation given is that some people who wanted shorter
context menus decided that they did not use the form commands very often and so
they removed the commands from the context menu.  We are just asking that it be
restored to the way it was before that decision was made.

> Scenario : If you are presented a form and Menus are not accessible, how do 
> you prefill the form or save the form data?  

That is a separate bug; we will at some point be adding a context menu item that
makes the main menu bar visible.


> These commands may not have been "context sensitive", in the sense that
> they only appeared at certain times during a right-click, but they *DID*  
> appear on the "context menus" that came up whenever you did do a right click.

I don't deny that in tho past they incorrectly appeared on the context menus.
That does not make them context sensitive.


> The right-click functionality that was there before is now gone.

Incorrect. The functionality is still there -- it's in the main Edit menu.


> I don't see what negative impact would be generated by having a "Form" 
> sub-menu in those cases when you right-click on a menu [sic] field; I can only
> see a postitive impact here.

Long submenus have a very serious impact on usability, as do submenus within 
context menus.


> The fact that the commands are available in the menus is not sufficient
> reason to remove them from a context menu.  If that WERE sufficient reason, we
> would have no context menus at all - because everything is available via the 
> menus.

That is totally incorrect. The majority of items on context menus -- especially
those for links, images and frames -- are _only_ accessible from context menus.


> The number of items when right-clicking in a form field is now *LESS* than the
> number of items when right-clicking in other areas of the browser. 

But these items you are asking for are not specific to a form field. It is very
bad practice to have items that affect the entire form appear as context-
sensitive items for form fields only. It's akin to having a "delete" button only
appear when a file is selected, but having it delete the entire all files.


> Those context menus are considered to have an acceptable number of items - 

Actually, the smallest page context menu has 10 items, which is considered
border-line maximum for a context menu (6 or 7 is ideal). So adding more items,
especially context insensitive items that are available from the main menu, is
not really an option.

Also, I am told by UI people that having multiple access points for features is
generally a bad idea because users tend to hesitate when deciding which to use
and thus any speed advantage of the different access points is lost.



> The situation here is that functionality has been taken away without warning 
> or explanation. 

This spec has been under discussion for well over 6 months.


This request is INVALID on account of it being bad UI on three counts and it
violating the published menu spec for Mozilla.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → INVALID
Whiteboard: INVALID? → WONTFIX?

Comment 17

17 years ago
If form fields are not at all context sensitive, then where does the context
menu (Undo, Cut, Copy, Paste, Delete, and Select All) come from when I right
click on a text field? 

I am not arguing with you about whether they are or not, just seeking information.

As for Blake's point that "The real, *real* problem is that our form filling
features are terrible.  They shouldn't require any menu items, main or context;
look at IE." -- I do not get it.  Is the objective here that because Mozilla's
form filling is not as good as IE's form filling, you want to make Mozilla's
form filling features less accessible?

Hixie, please direct me to where I can find information on the discussion of
whether or not these particular items should be in the web page context menu. I
am aware that specs for changing the context menus has been under discussion for
some time now, but I can not find anywhere that explains why these items were
removed.  I realize that you are giving an explanation now, but my comment was
about before.

Comment 18

17 years ago
Ignore my question about form text field context menus; my brain was confused
for a moment on what had been said.  I blame it on my medication.

Hixie, was is the bug number for the context menu to bring up the menus?

Comment 19

17 years ago
>But these items you are asking for are not specific to a form field. It 
>is very bad practice to have items that affect the entire form appear as 
>context-sensitive items for form fields only. It's akin to having a "delete"
>button only appear when a file is selected, but having it delete the entire 
>all files.

So should a bug be filed to make a form area between form tags be detectable so
that we can have form context sensitive items in a context menu?  This bug would
then depend on that one
(Reporter)

Comment 20

17 years ago
>Having the items available only when right clicking on a form element
>would give the mistaken impression that the items are context-sensitive,
>which they are not.

But if they only appeared when you right-clicked on a form field they WOULD be
context-sensitive.  By definition.  They'd only appear in the context of
right-clicking on them. <grin>  (This is just looking at the same thing from two
different perspectives.)

>> The right-click functionality that was there before is now gone.
>Incorrect. The functionality is still there -- it's in the main Edit
>menu.

The functionality is still there.  The *right-click* functionality is gone.  It
was far easier to use these commands previously.  Using them via the menu is
somewhat cumbersome and takes at least 3 times as long.

>But these items you are asking for are not specific to a form field.
>It is very bad practice to have items that affect the entire form
>appear as context-sensitive items for form fields only.

Correct, they are specific to the whole form.  But the form fields are a sub-set
of the whole form.  If I want to Prefill a form, I want to prefill all of its
fields, not just one of them.  (Also, a case could be made that the command *IS*
specific to each/all of the form fields.)

(Is there anywhere else on the "form" that you could click that would be
considered part of the form but not a specific form field?  I'm assuming it
natural that selecting a field is an implicit selection of the form.)

>This spec has been under discussion for well over 6 months.

Can you point me to the location of text / discussion regarding the
specification that specifically addresses these form commands and whether or not
to include them?

>it violating the published menu spec for Mozilla.

Is what you refer to as the "published menu spec" this:
http://www.mozilla.org/projects/ui/communicator/framework/contextmenus/index.html 

This was referred to on Mozillazine and I'm going to look at it shortly.

>Sorry, but you're never going to convince me :-)

Probably not. <grin>  And I'm about to pack it in.  But my forcing the
discussion has resulted in learning some valuable information that wasn't
immediately obvious before.

One last question.  Would it be worth my time to file a bug on having a keyboard
shortcut for "Prefill Form" (or "Fill In Form" depending on how you want to word
it)?  Really, my objection here is that taking it out of the right-click menus,
while not making it impossible to use since it *IS* still in the main toolbar,
still makes it more cumbersome and time consuming.  A simple right-click in a
form field followed by a left click was far easier and less time consuming than
having to mouse up to Tools -> Form Manager -> Fill In Form.  If I could get to
the page in question with the form and issue a simple keyboard shortcut that
would be just as, if not more, convenient than even the old method.  If I open
such a bug is it likely to be marked INVALID right away?  I don't want to start
on another "crusade" if it's doomed to failure before it starts. <grin>
(Reporter)

Comment 21

17 years ago
Opened bug 136037 to get a keyboard shortcut for Prefill/Fill In Form. 
Hopefully that one won't go the way of this bug.

Comment 22

17 years ago
One more comment that makes need for right-click form menu more important - how
to manage forms in pop up windows, that open with no menu??

Comment 23

17 years ago
*** Bug 135919 has been marked as a duplicate of this bug. ***

Comment 24

17 years ago
*** Bug 143677 has been marked as a duplicate of this bug. ***

Comment 25

17 years ago
Right-click form management was quite important feature for me and only one of
few that makes Mozilla my preferred browser against MSIE. I am going back to
ver. 0.9.8, that has this functionality. Is this really the way users of Mozilla
should go???

Comment 26

17 years ago
Continuation of comment 21:
   Bug 136037 has been duped to the more general bug 143881
mass-verification of Invalid bugs.

if you don't think the report is invalid, please check to see if it has already
been reported (it might be a duplicate instead). otherwise, make sure that there
are steps (a valid test case) that clearly display the issue as an unexpected
defect.

mail filter string for bugspam: SequoiadendronGiganteum
Status: RESOLVED → VERIFIED
*** Bug 178455 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite

Updated

10 years ago
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.