343624 - pasting into forms/text-input: anything after first line-break is lost.

Status: RESOLVED DUPLICATE of bug 77932

(Toolkit :: Form Manager, defect)

Description

[Dak]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

If copy/pasting into a text box in firefox, any line breaks in the text to be pasted will result in only the text up to the first line break being pasted.


Reproducible: Always

Steps to Reproduce:
1.Copy the following into clipboard:

hello. i cover
two lines.

2.focus a text-input box in FF. can be the address-box, the search-box, or a form textbox.
3.paste.


Actual Results:  
"hello. i cover" is pasted into the box


Expected Results:  
"hello. i cover two lines." should be pasted into the box.

i.e., if possible, line breaks should be parsed as white spaces when pasting into FF text-boxes.

I dont believe this hasn't been submitted, but i couldn't find it anywhere.

sorry if it's a resubmission.

Comment 1

[Ralf Vitasek]

this has a good reason.

the input fields cannot hold linebreaks at all.
what you seem to expect is that the pasting operation would kill linebreaks just in case you paste into an input box.

and btw. all other browser handle this the same way.

Comment 2

[Uri Bernstein]

(In reply to comment #1)
> 
> and btw. all other browser handle this the same way.
> 

Wrong. Opera 8.5 (on Mac, at least) does what the bug submitter requests: it strips the linebreaks when pasting into single-line input fields.

Comment 3

[Uri Bernstein]

Reporter: you get get the behavior you desire by setting the value of the "editor.singleLine.pasteNewlines" preference to 3.

Comment 4

[Ralf Vitasek]

changing to duplicate

Comment 5

[Ralf Vitasek]

changing to duplicate

*** This bug has been marked as a duplicate of 77932 ***

Comment 6

[Dak]

thanks mightily :)

although, setting it to 2 would make more sence:

hello. i cover
two lines.

(with value at 3)

hello. i covertwo lines.

(with value at 2)

hello. i cover two lines.

note, with the value at 3, 'covertwo' results, thus breaking any searches.

May i suggest that this value is set to 2 as default? or is there a reason for it being 1 as default?

Comment 7

[Uri Bernstein]

(In reply to comment #5)
> 
> *** This bug has been marked as a duplicate of 77932 ***
> 

I'm not sure about that. Bug 77932 is about Linux - where the default setting of editor.singleLine.pasteNewlines is 0 (meaning that the newlines are actually pasted into the single-line input).
This report, on the other hand, is about Windows, where the default setting is 1 (the text is truncated at the first newline).

See bug 77932 comment #15.

Comment 8

[Uri Bernstein]

(In reply to comment #6)

> May i suggest that this value is set to 2 as default? or is there a reason for
> it being 1 as default?
> 

Bug 283813 comment #1 claims that "there are reasons why this [3] isn't default, read that bug [77932] for that". But I haven't been able to find these reasons, and also, that comment was wrong in duping that bug to bug 77932.

So, I don't know what the reasons were for making the default "1" (on Windows and Mac). IMO, the request to change it to "2" is valid.

Comment 9

[Uri Bernstein]

See bug 50935 for where the current defaults were decided. Note bug 50935 comment 10 which calls for making the default 2 or 3.

Comment 10

[Dak]

hmm... some good points in those bug discussions.

Setting the default to 1 is, imo, not good in any way shape or form (unless i missed something).

setting the default to 2 will work for forms and search-boxes, but will brake urls that have /n in them.

(e.g., 

hxxp://www.example.com/reallylongfilepath/blah
blahblah/page.html

will get copy/pasted with a space inbetween the first and second 'blah', thus breaking the url), 

whereas 3, whilst working for copy/paste muli-line urls, will break most other form/search inputs, fusing two words together.

hmm... could FF auto-choose it's behaviour based on the context? i.e., in the address box, could it behave as '3', whilst in other text-boxes behave as '2'?

for ease of refference, the numbers are:

0 (default in Linux): Paste content intact (include newlines)
1 (default everywhere else): Paste the content only up to (but not including) the first newline
2: Replace each newline with a space
3: Remove all newlines from content
4: Substitute commas for newlines in text box

Comment 11

[Uri Bernstein]

(In reply to comment #10)

> hmm... could FF auto-choose it's behaviour based on the context? i.e., in the
> address box, could it behave as '3', whilst in other text-boxes behave as '2'?
> 

The address bar case was already fixed (on the trunk) in bug 23485, by setting the behavior for that field specifically to "eNewlinesStripSurroundingWhitespace" (which is like 3, but also strips whitespace adjacent to the newlines) - regardless of the value of editor.singleLine.pasteNewlines.