Closed Bug 391936 Opened 17 years ago Closed 17 years ago

Pasting multi-line text into search bar or single line input field should strip '\n'

Categories

(Firefox :: General, defect)

x86
Windows XP
defect
Not set
minor

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: thephilips, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Pasting multi-line text into location bar does paste only first line. This is relevant to: - keyword/web search feature, when e.g. you try to google for something and paste text to be searched copied before from web page which turned out to be multiline - pasting text into form fields from other applications Reproducible: Always Steps to Reproduce: 1. Select following text (with/without quotes): "Hello World!" 2. Press Ctrl-K to focus web search field 3. Press Ctrl-V Actual Results: Only first line (Hello) is inserted Expected Results: Newline(s) should be replaced by white spaces and "Hello World!" should appear in search box. This is not critical, but in some cases it becomes PITA, since Mozilla tries to recreate formating when copying text into clipboard. And since formatting isn't always apparent, later pasting the text into form/search field/location bar become pretty impossible w/o running extra application (terminal/notepad) and removing manually the newlines. I presume the change is pretty simple and would have no side effects, since pasting multi-line text into single line form element isn't defined anyway. At least pasting whole text replacing newlines by spaces is something meaningful and useful, compared to never-desired pasting first line only.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Location bar problem was fixed-on-trunk, the single line form field problem seems to be a separate bug, for I still see it in the latest trunk (Win XP).
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
When I paste javascript: open('http://www.yahoo.com/'); void 1 into the properties field of a bookmark it pasts only the first line.
OK. I see. My presumption that the paste functionality is handled uniformly - by some input widget/control - was wrong. My list of places where I hit the problem is - location bar (i am heavy user of keyword searches); - bookmarks/live bookmarks properties (when I populate manually created bookmark with new search terms and the search terms are copy-pasted); - plain input fields in forms on web pages; - google toolbar input field; - web search in location bar. I expect that most people would notice the defect only in form input fields - since they are used most often. Location bar and bookmarks are changed by normal users manually very very rarely.
location bar is fixed stripping \n, while in search bar and single line input fields maybe should be better a replace with a space. since that was fixed in locationbar on Trunk also this could be a valid one, updating title.
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Pasting multi-line text into location bar/single line form field → Pasting multi-line text into search bar or single line input field should strip '\n'
OK. This bug isn't dupe. The guys really are indecent and really "strip" newlines from everything pasted into location bar. That makes the feature pretty useless, since user in 90% of cases doesn't control what he pastes into location bar: most likely it was just copied from open web page. (At least that what I do most often.) Stripping '\n' is WRONG. Replacing with spaces - is right.
There's already a bug on the search bar -- bug 321000. There have been many bugs on what happens in <INPUT>, and iirc we have platform-dependent behavior there. I think on Linux we preserve newlines (which makes no sense to me, but was seen as platform-compat at one point), whereas on other platforms we truncate at the first newline (also platform compat). Given the confused nature of this bug, it should probably just be RESOLVED INVALID anyway.
This was probably fixed by bug 406062 (we'd already fixed the search bar and location bar separately).
Status: NEW → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.