Closed Bug 32926 Opened 25 years ago Closed 25 years ago

Users can paste a tab character into single-line text fields

Categories

(Core :: DOM: Editor, defect, P3)

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: elig, Assigned: rubydoo123)

Details

* TITLE/SUMMARY Users can paste a tab character into single-line text fields (Thanks to Matthew Thomas for noting this on the n.p.m. newsgroups) * STEPS TO REPRODUCE 0) Launch Seamonkey 1) Launch a text editor, press the tab key, and copy it. 2) Launch Seamonkey, select the URL field, and choose paste the clipboard. * RESULT - What happened The tab is pasted into single-line text field, even though users wouldn't have been allowed to enter a tab character by pressing the tab key. - What was expected Matthew suggests that the tab character shouldn't be allowed into a single-line text field by paste if it isn't allowed by actual typing. I don't feel strongly either way --- we can't enter the tab character because it's used for selecting fields. Unless there are adverse effects to placing a tab character into the URL field, what end-user impact occurs from being able to paste it there? I don't think we should be stripping tabs out of multi-line pastes --- people may wish to copy tab-formatted text into a multi-line text field, such as this bug report. ;) So, I defer to y'all to duke it out, and I'll happily verify whatever resolution y'all like. * REGRESSION - Occurs On Mac OS, Win32, Linux Seamonkey (3.22.00 AM beta 1 commercial optimized build) - Doesn't Occur On Communicator 4.72 RTM (Mac OS) * CONFIGURATIONS TESTED - [Mac] Beige Power Mac G3 (266 MHz PowerPC 750), 96 MB RAM (VM on; 1 MB of VM used), 1024x768 (Thousands of Colors), Mac OS 8.6 - [Win32] Vectra VL (233 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP5. - [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).
Reducing severity to 'trivial' based on information available, and QA Assigned to self.
Severity: normal → trivial
QA Contact: sujay → elig
Target Milestone: ---
I think we should allow tab to be entered in single-line plaintext widgets, just like they can be in multiline. I don't understand what we would gain by not allowing them, and why we should complicate the code by disallowing them. I think we should WONTFIX this and say it's working as designed. Adding jfrancis since this would presumably be a rules issue.
Complicate the code? Hello? What about complicating the user experience? ... It doesn't make sense to me that you can't type a character somewhere but you can paste it into the same place. So, any tab pasted into a single-line text field should be converted to a space.
To me, it complicates the user experience to see tabs (which look like multiple spaces in most apps) converted to a single space, and to see information lost when pasting to single line text fields when it's not lost when pasting to multi line. And as far as I know, you can type a tab in a text field, if that text field is not living on a page which uses tabs for its own purposes (e.g. if there's only one input field on the page).
Hmm...Matthew, three questions: #1: What scenarios can you think of in which a user would deliberately paste a tab character (or text containing a tab character) into a single-line text field, and find the result of the tab being pasted to have adverse effects? If so: 1a) If so, can you think of scenarios in which users would be confused by the tab character that they copied in fact being pasted? #2: What scenarios can you think of in which a user would copy text containing a tab character, and be confused at why the tab character wasn't present? If so: 2a) Given that the tab character isn't stripped from multiline text fields, can you think of scenarios in which users would be confused as to why tabs weren't copied in single-line text fields, but were in multi-line text fields? Yours, Eli
Okay. 3+1 questions.
1: Are you volunteering to test all the consequences of allowing tab pasting in every text field in Mozilla? Does the e-mail system (Mozilla client, server, or any other RFC-compliant client) barf if there is a tab character in a user-entered message header? Does the address book database barf if there is a tab character in one of the fields? Does the address book export produce erroneous data if I try to export the address book as tab-delimited text (once that's implemented), and one of the address book records contains a tab character already? Does Messenger barf when I try to use a mail server with a name containing a tab character? ... And so on, and so on, and so on. Given that tab entry into a single-line text widget is not possible with direct typing, very few XPToolkit programmers will expect that it is possible at all; and that will inevitably lead to unexpected behavior if a tab character *is* input. 1a: A simple example is the various search functions. If I get an e-mail message with the subject "a<tab>b" (which looks like "a<space>b"), and I forget where I put it and do a search for all messages with the subject "a<space>b", will I find the message? If so, how? And if not, why not? Conversely, if I copy the text "Eli<tab>Goldberg" from somewhere (a tab-delimited database, for example), not realizing it has a tab character in it, and I then paste it into a search field for my bookmarks or address book or whatever, which contain references to "Eli<space>Goldberg", will I find anything? If so, how? And if not, why not? 2: I can think of no scenarios where a user would expect a tab to remain a tab when *pasted* into a single-line text field, given that a tab can not be *typed* into a single-line text field! 2a: No -- since tab characters can be typed into multi-line text fields, it makes sense to the user that they can also be pasted into multi-line text fields. But talk to lake@netscape.com: it's by no means certain that multi-line text fields will be able to accept tab characters either -- that's currently under debate.
reassign to me
Assignee: brade → beppe
Users should be allowed to paste in the contents of the clipboard, whether that be character data or control characters. Pasting a tab into a text field is allowable. The spec defers this function to the user agent. Consequently, on the paste function we paste in a single space. The tab function is used for navigation, so when a user has selected within a text field or textarea and select tab, the navigation takes control. However, tabs can be used within mail compose and composer. Pasting a tab into the URL field results in the insertion of the ascii code %09 -- which is correct. The end result, the app is working as designed.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
Lisa, might you have any comments on Matthew's 2000-03-24 04:43 notes. Specifically, do you know of any reason to believe that (1) and (1a) are not scenarios that could lead to problems in Mail/News?
My comments regarding those are: 1) if there are special characters that shouldn't be inserted into a mail header, I'd say it's up to someone to filter those out. For example, if high-ascii characters (e with an accent) are not permitted then those should be filtered out by the consumer of the text widget. I am not sure that tab is any more different than other characters such as e with an accent. btw, it is possible to type a tab into a textfield; the catch is that usually the navigation grabs the tab first and the textfield doesn't always see it. 1a) In the case of the web database that you want to query, if it's a half-decent database it should normalize it's data not do any conversion for you. Along with converting tabs into spaces, I'd expect it to compress multiple consecutive spaces as well so I wouldn't have to query for "Eli Goldberg" and "Eli Goldberg" I can imagine that some web applications might want users to paste tab delimited data so it can parse the data as it needs to.
Since beppe has the final word, I'm going to rubber-stamp this as Verified/WontFix. --- Matthew/Lisa/anyone, if you can identify specific bugs resulting from the ability to insert a tab character that you feel should be fixed by eliminating the ability to add a tab character, please feel free to re-open this bug. I've e-mailed Lisa Chiang to be sure she sees the request to double-check whether tab characters inserted in this fashion could cause problems in her feature areas down the line.
Status: RESOLVED → VERIFIED
I will check out the comments here on Friday. Thanks.
setting to an approximate milestone so it can be off of the no TFV list
Target Milestone: --- → M15
You need to log in before you can comment on or make changes to this bug.