Firefox/Feature Brainstorming:Form handling and text areas: Difference between revisions

 
(32 intermediate revisions by 19 users not shown)
Line 1: Line 1:
{{FeatureBrainstorming}}
{{FeatureBrainstorming}}
== File upload form elements ==
Provide an easy way of clearing a pre-filled file browse element. It's a problem on forums and message boards in particular where you have an optional file element. Select a file by mistake (or use the back button and have it filled with something you've just uploaded) and your only option is to reload the page (and clearing the cache in some cases). Perhaps give it a right click menu with a clear/delete option? [[User:Abigsmurf|Abigsmurf]] 18:11, 6 June 2010 (UTC)
:This is filed as {{bug|431098}} --MattN 03:51, 11 June 2010 (UTC)
== Text input field navigation improvements  ==
*Allow {TAB}-key navigating 'through input fields only'. Pressing the {TAB}-key lets today's Firefox annoyingly jump to the next hyperlink (!) and option button (!), too, so that it often takes very long to select the next text input field (including the web adress bar and search bar). Hyperlinks and option buttons etc. can be used easier by mouseclicking, but input form fields could be selected faster by {TAB} and {SHIFT}-{TAB}. - [[User:Gutzndaifi|Gutzndaifi]] 09:14, 25 October 2007 (PDT)
*Maybe this can be integrated into an add-on like 'Highlight Focus' by Rudolf Noe, located at [https://addons.mozilla.org/en-US/firefox/addon/1310] etc., but it would be much better to implement it 'as standard'. - [[User:Gutzndaifi|Gutzndaifi]] 09:14, 25 October 2007 (PDT)
*On Firefox for the Mac, allow (TAB)-key navigating between other types of objects in a form. Currently, pressing TAB only navigates between text fields. Please add the ability to navigate to combo boxes, check boxes, radio buttons, buttons, etc. -JK 30 March, 2008
*I love the idea of separate tab queues for forms, links, images, i dunno what else. Forms and links are the two biggies IMHO. This is the only feature the keeps Opera installed on my box. Please Please Please may we have it? :) -CD 23 May, 2008
*Many pages will automatically place the text cursor in a particular text box only after a given percentage of the page has loaded (for example, Gmail places the cursor in the username field). However, one can manually begin information in whatever field before this occurs by clicking on that field. It is frustrating when, in the middle of typing something, the cursor is automatically relocated. Mozilla should include a feature whereby the manual placement of the cursor overrides the auto-placement.<br>
== Caution User when about to lose form data to the back button<br>  ==
*When the back button is pressed (or backspace on the keyboard accidentaly pressed), and some form element on the page has been edited but not submitted, display a dialog telling the user they are about to lose what they typed. The dialog could of course have a checkbox marked do not show this message again.
There is nothing more aggravating than losing a long post because you thought that a text field had focus. This way, <br>
== Web Forms 2.0 implementation ==
== Web Forms 2.0 implementation ==
* Allow using of the extended forms. See the standard made by whatwg, which is located at [http://www.whatwg.org/specs/web-forms/current-work]
* Allow using of the extended forms. See the standard made by whatwg, which is located at [http://www.whatwg.org/specs/web-forms/current-work]
Line 33: Line 53:
Enhanced the TEXTAREA tag to provide a WYSIWYG editor that generates HTML code.  How many different Javascript, ActiveX, Applet and AJAX solutions exist for this problem?  How many of them <u>actually work</u>?  None.  Let's fix this problem once and do it right.  Imagine:
Enhanced the TEXTAREA tag to provide a WYSIWYG editor that generates HTML code.  How many different Javascript, ActiveX, Applet and AJAX solutions exist for this problem?  How many of them <u>actually work</u>?  None.  Let's fix this problem once and do it right.  Imagine:


  <TEXTAREA NAME="foo" TYPE="wysiwyg">
  <textarea id="foo" type="wysiwyg"> </textarea>


The user would see a text box with WYSIWYG editing controls.  When the form submits, the field would contain HTML code for the user's content.  Other browsers would ignore the new flag and display a standard TEXTAREA.
The user would see a text box with WYSIWYG editing controls.  When the form submits, the field would contain HTML code for the user's content.  Other browsers would ignore the new flag and display a standard TEXTAREA.
Line 39: Line 59:
<u>EVERYONE</u> needs this, including this Wiki.
<u>EVERYONE</u> needs this, including this Wiki.
:However we would be breaking the standards, wouldn't we? And i think we shouldn't be trying to do W3C's job.
:However we would be breaking the standards, wouldn't we? And i think we shouldn't be trying to do W3C's job.
*This should act like <tt>div</tt> element with <tt>contenteditable</tt> attribute. DOM content should be acessibile and <tt>execCommand</tt> should work. --[[User:Ziga|Ziga]] 15:49, 13 February 2007


== Use mouse wheel to modify the values ==
== Use mouse wheel to modify the values ==
Line 53: Line 75:
or
or
* provide a separate page or a tab in Page info where the contents of forms that are sent last are shown.
* provide a separate page or a tab in Page info where the contents of forms that are sent last are shown.
There should definitely be some way to recover data that has been typed into a form and then lost.  Cache everything typed into forms, make it available on an about:textareas page or something, so we can recover our ten minutes of typing even if the page crashes, changes, gets logged out, etc. and Firefox can't figure out how to re-fill it.


== Autofill forms ==
== Autofill forms ==
Line 60: Line 84:
* Like Internet Explorer - it is best way.
* Like Internet Explorer - it is best way.
* With Firefox 2, login form fields are only filled in with the login information stored in password manager after loading of the entire page has completed. However, form fields (in particular for login) should be rendered before any other elements on a page, because often all you want to do on a login page is ... to log in. But instead, rendering of a login page often hangs because billions of annoying ad servers take forever to reply to client requests. Rendering (login) forms and filling in the login information first would allow for immediate login, without having to wait until rendering of the whole page is complete -- also contributing to save bandwith, as requests to the billions of annoying ad servers would not be send, or at least cancelled immediately.
* With Firefox 2, login form fields are only filled in with the login information stored in password manager after loading of the entire page has completed. However, form fields (in particular for login) should be rendered before any other elements on a page, because often all you want to do on a login page is ... to log in. But instead, rendering of a login page often hangs because billions of annoying ad servers take forever to reply to client requests. Rendering (login) forms and filling in the login information first would allow for immediate login, without having to wait until rendering of the whole page is complete -- also contributing to save bandwith, as requests to the billions of annoying ad servers would not be send, or at least cancelled immediately.
* Allow for check boxes to be filled based on the box being highlighted. So that if 10 check boxes are highlighted, you can fill them all in in one task not ten individual button clicks.


== User-created spell check blacklist ==
== User-created spell check blacklist ==
Line 68: Line 93:


* Allow users to submit form buttons to a new tab/window
* Allow users to submit form buttons to a new tab/window
 
* [https://addons.mozilla.org/en-US/firefox/addon/483 Submit To Tab] Extension by nrlz
* [https://bugzilla.mozilla.org/show_bug.cgi?id=17754 Bug17754] Ability to submit form in a new window / tab
<br><br>
'Minor' Edit made; [[User:Nu(-)Ne(Ø)|_(-)(Ø)_]] 21:44, 29 December 2007 (PST)▼
<br>Apparently, context Menu Items like these aren't a big deal; at least not to the developers who are supposed to implement them, to my awareness thereof. Which is probably Why the Context Menu Item "View Image in New Tab" Option(amongst many other context menu Items mind you) is, Strangely, absent from the context Menu of Images(and to other respective/relevant objects as well) :O. That, or they just forgot about conveniences like that and need to be, reminded ;), ;).<br><br>
But I second the notion you've stated for a "Submit in New Window" and "Submit in New Tab" Context menu Item to be added to form like JavaScript based(?) Buttons as I to feel that it was, shall I say, "Left to be desired" :).
<br>
<br>
Please remove my input herein, if need be so.


== Change the way the spell checker highlights the misspelled words ==
== Change the way the spell checker highlights the misspelled words ==


User interface consistency is important. I think misspelled words should be underlined with a red zigzag line, much like it's done on all modern text processors, instead of the current dotted line.
User interface consistency is important. I think misspelled words should be underlined with a red zigzag line, much like it's done on all modern text processors, instead of the current dotted line.
[https://bugzilla.mozilla.org/show_bug.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&id=17754 Bug17754]
[https://addons.mozilla.org/firefox/240/ Submit forms in a new tab/window ](Firefox Extension - Submit To Tab by nrlz)


[added:stk 10-mar-07]
[added:stk 10-mar-07]
Line 88: Line 119:


When I am reading a long article, paging down, it is annoying to reach the last page only to find that it is shorter than all the other pages and now my place is lost somewhere in the middle of the screen. I have to hunt for where I left off. I could solve this using the mouse to scroll, and sometimes I do, but I find that more burdensome than just hitting page down. This behavior has existed since the earliest days of the web. It seems to me the easiest way to fix it is for the browser to position the last line of the current page as the first line of the next, no matter what, and fill the rest of the window as needed with blank space. Since I spend most of my web time reading text, consistent text positioning would be a major usability enhancement for me.
When I am reading a long article, paging down, it is annoying to reach the last page only to find that it is shorter than all the other pages and now my place is lost somewhere in the middle of the screen. I have to hunt for where I left off. I could solve this using the mouse to scroll, and sometimes I do, but I find that more burdensome than just hitting page down. This behavior has existed since the earliest days of the web. It seems to me the easiest way to fix it is for the browser to position the last line of the current page as the first line of the next, no matter what, and fill the rest of the window as needed with blank space. Since I spend most of my web time reading text, consistent text positioning would be a major usability enhancement for me.
'minor' edit made; [[User:Nu(-)Ne(Ø)|_(-)(Ø)_]] 21:57, 29 December 2007 (PST)▼
You know what'd be a sweet Idea?
<br># 13 of my list: Memory Markers of some sorts that you can "place" on the page so that when you go down or up the page, right click off the scrollbar and input a # or something, it would send you to the corresponding part of the page. Maybe a Context Menu Item that states something along the lines of "Place memory marker on this currently displayed position" with extra Context Items added to the list and set as Numbers so you can seamlessly scroll anywhere on the current page. I haven't fully gone into the details of its implementation but I'll work on it when I get the proper inspiration.
<br><br>Thanks however for your proposal as I often wondered if anyone else had the same Idea ;).
<br>
<br>
Please remove my input herein, if need be so. ▲


== Drag and dropping files into textboxes ==
== Drag and dropping files into textboxes ==
Line 111: Line 151:
* The clipboard does not affect copy and paste in any way. It merely pastes all instances of copying into its memory. Pasting an item from the clipboard merely copies the item from the history and pastes it, as if the user did it manually.
* The clipboard does not affect copy and paste in any way. It merely pastes all instances of copying into its memory. Pasting an item from the clipboard merely copies the item from the history and pastes it, as if the user did it manually.
* The order of the items on a clipboard can be sorted via up/down buttons.
* The order of the items on a clipboard can be sorted via up/down buttons.
'Minor edit' made [[User:Nu(-)Ne(Ø)|_(-)(Ø)_]] 22:13, 29 December 2007 (PST)▼
You know, on KDE we have this thing called Klipper. It is shear Awesomeness! It is, or can be, almost as your description depicts. Except, its a Tray Icon instead of a sidebar. I don't think a sidebar would be very, space friendly, you know? Floating clipboard provide ease of access and is space considerate. I think the problem would be, as I am assuming, that it would get in the way of the cursor sometimes. I don't see why we can't have it as, a Sidebar, Toolbar, and Float. Just Position it to the right or left pane for sidebar preference, Up near the top for Toolbar preferences, and anywhere in between for floating preferences with context options for displaying said clipboard as such.
<br><br>
Still that would be a good thing to have when you want to download many specific things from a page while Browsing using Firefox :).
<br>
Please remove my input herein, if need be so.▲


== Allow specified textareas to expand with the size of the window ==
== Allow specified textareas to expand with the size of the window ==
Line 124: Line 172:
Some forms require clicking a series of routine "submit" buttons.  Some of the button-clicking has to do with accepting security certificates.  It's good that Firefox can remember the user IDs and passwords.  It'd be better if Firefox allows us to "record" the sequence of button clicking as a macro files, and allows us (end users, not Web masters) to replay those macro files with a single click of a button.
Some forms require clicking a series of routine "submit" buttons.  Some of the button-clicking has to do with accepting security certificates.  It's good that Firefox can remember the user IDs and passwords.  It'd be better if Firefox allows us to "record" the sequence of button clicking as a macro files, and allows us (end users, not Web masters) to replay those macro files with a single click of a button.


== Show link to open target ==
----
When the pointer or focus is on a link to a page that is already open in the browser, show the link visually as a line from the source to the target. When a link to an anchor is followed, flash a circle around the anchor on the page. This fixes two common problems: not knowing where the link is supposed to follow, if the page is too short to be scrolled, and not seeing the context before the link because if the page scrolls the anchor to the first line.
--[[User:Paulmackinlay|Paulmackinlay]] 04:42, 25 May 2007 (PDT)
This feature would be very useful and can be extended further to be even more useful. If the macros could be saved, categorised, edited this could form the basis of a powerful web testing suite. Firefox has always had great web-app developer aids and this would be certainly one of the most useful since it could be used to generate test suites which would be fully automated functional tests. It would ensure the web-app it behaving as expected with the current version of gecko and rhino.
 
Assertions would need to be made available, which would indicate if a test passes or fails. It would also be useful to modify parameters such as domain name and port so that the same tests can be executed on more than one environment.
 
Actually, there is a great piece of software called Badboy[http://www.badboy.com.au/] which does something similar, it has a lot of excellent features. Unfortunately it is only available for a specific OS and becuase it is not portable I can't use it. I appreciate that web-app testing is probably beyond the scope of core Firefox but maybe a seperate component/plug that does this could be considered.
 
----
[[User:Glest|Glest]] 03:19, 19 February 2008 (PST)
I don't really like the idea of building a macro system in a browser. It would make it very easy to spam forms. I know it's already easy, but atleast there is no standard browser function called "Spam form".


== Annotations ==
== Searchable button labels ==
Allow the browser to make annotations of arbitrary parts of text and publish them as web pages.  Publishing will require servers, which can be provided by volunteers initially, and businesses when the concept is proven.
Make button labels searchable, so that you can text search (for example) this page for "Search" and have the cursor on the "Search" button at the topThis would help with navigation, especially in large webpagesFirst, like text search in general, it allows the focus to be positioned directly without using a pointing device, which is often fasterSecond, there is often a specific button or function (such as search) which users want to use and have to scroll through the page and look for it manually. -[[User:Pgan002|Pgan002]] 15:07, 8 May 2007 (PDT)
* How would you be able to get companies to go along with this? Most corporations would be afraid people would attach annotations to their pages and start spamming. Also, how would you address some pages that are collectively represented by one URL? --[[User:Armaetin|Armaetin]] 16:37, 28 March 2007 (PDT)
** Companies, and all web page authors, would not have a say in what others publish about their web pages, just as today.  The difference with annotations is that they are easier to create and link to a portion of a web page.  This is a vehicle for free speech, global understanding and democracy.  Users will be able to choose to see or hide the annotations of a web page they are visiting. 
** Your second question may be asking several different things.  Annotations may be stored together with a digest (MD5 sum) or cached local copy of the web page or portion of page that they refer toThen those can be compared with the rendered page to automatically check that the annotation appliesIf you want to annotate any page represented by some URL (for example, a dynamically generated page), do not associate any content with the annotation.  Annotations can also apply to sets of pages represented by different URLs.  An annotation consists of an HTML document (description) and a generalized link to a list of content on addressed pagesAn element in the list can be specified as a start and end address in the given document, possibly together with a digest of the content.
*** Ok, I get it. However, I think this should be optional (and by optional, I don't mean hiding the annotations; when annotations is turned off, it should be as Firefox didn't have the feature) for the user because having annotations is equivalent to loading two pages for every one, thus hindering some of those who have slower Internet connections or bugging those who do want to see annotations. Another concern that I have is that some webs sites may feel that annotations threaten their businesses. After all, why pay to put your advertisement on a website when you can attach an advertisement to an annotation? Many websites that currently provide free services could begin charging users because they feel that the advertising business could become marginally profitable. Other than that, a good (if not revolutionary) idea. Perhaps, if this becomes successful, users should be able to pick from whom they want annotations from. --[[User:Armaetin|Armaetin]] 16:37, 28 March 2007 (PDT)


== Zoom ==
== Easy clearing of bad completions ==
Allow the user to increase and decrease (zoom) all content on a rendered web page, including text, images and flash, at the same time by the same factor.  This should be possible using only the keyboard or using only a pointing device, and the current zoom factor should be shown in the status bar.
Add an "X" button to the end of each line in the completion list that removes the entry.  This would allow you to get rid of accidental typos in previous forms that will pop up (without having to clear ALL the form completion data.)  -[[User:EricBayer|EricBayer]] 22:10, 3 July 2007
* I think this should be optional because it might be aesthetically displeasing to some. I am assuming Mr. EricBayer is unaware that he can get rid of saved form entries using Shift+Delete? --[[User:Armaetin|Armaetin]] 22:48, 3 July 2007 (PDT)


== Remember which page and window a page was opened from ==
Remember which page and window (tab) a page was opened from.  Then allow the user to go back to that tab or window.  This extends the concept of browsing history and helps users to grasp how the content in visited pages relates together.


== Remember chosen language for every text area on every page ==
For polyglot users, the Spell Checker loses much of its appeal, because you must manually switch the language every time you switch between languages.


== Don't use key 's' as shortcut for menu ==
If the checker simply remembered the language I chose for each web page and on a second level for each text area on that web page (probably hard to impossible), it would greatly simplify writing for polyglot users. So, if I write on English wikipedia it first checks which language header the web site sent and if I don't agree with that setting, I can choose my own - maybe British English, even though Wikipedia sends US-English headers - and the checker will remember my choice, when I revisit the page.
Currently pressing ALT + 's' opens the 'History' menu. This is really annoying since a lot of board pages use the shortcut ALT + 's' to submit new posts.


===Workaround===
Another idea would be auto-recognition and multiple languages, but that's not too easy I guess, especially if the detection is based on the users misspellings.
Change to about:config and change the following values:
I don't know whether there already is some sort of JS-Handler, but if web sites could tamper with Firefoxes Spell checker, they could suggest the right language right away - and annoy users a lot if they have bad intentions, of course.
ui.key.chromeAccess into 5
--[[User:Rubenarslan|Rubenarslan]] 09:11, 4 November 2007 (PST)
ui.key.contentAccess into 4
8

edits