<a class="header-button" href="https://bugzilla.mozilla.org/home" title="Go to home page"> Bugzilla

Assignee

Comment 2

•

23 years ago

This is by design. Access them from the Edit menu.

Status: UNCONFIRMED → RESOLVED

Closed: 23 years ago

Resolution: --- → WONTFIX

Reporter

Comment 3

•

23 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

•

23 years ago

The form commands are not context-sensitive.

Reporter

Comment 5

•

23 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

•

23 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

•

23 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 → ---

Hixie (not reading bugmail)

Reporter

Comment 8

•

23 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".

Comment 9

•

23 years ago

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

Closed: 23 years ago → 23 years ago

Resolution: --- → WONTFIX

Whiteboard: INVALID?

Comment 10

•

23 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

•

23 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

•

23 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

•

23 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

•

23 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.

Hixie (not reading bugmail)

Comment 15

•

23 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.

Comment 16

•

23 years ago

> 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

Closed: 23 years ago → 23 years ago

Resolution: --- → INVALID

Whiteboard: INVALID? → WONTFIX?

Comment 17

•

23 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

•

23 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

•

23 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

•

23 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>