406062 - set editor.singleLine.pasteNewlines to 2

Status: RESOLVED FIXED

(Firefox :: General, defect, P3)

Description

[Mike Connor [:mconnor]]

Attachment: set pref to 2 in firefox.js

This now works correctly, and is tremendously useful for mapping sites etc.  Its on the UX bugs list, we should just do it.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

I'm not sure I'm really the right person to review this - what caused this to now work correctly?

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 290731 [details] [diff] [review]
set pref to 2 in firefox.js

ui-r+

Gavin: there was a bug a few milestones back that got fixed which changed this so that it only affected input type=text in content, not chrome, which is the one mconnor was referring to.

I've been browsing with this pref for months, and it's nothing but useful.

Comment 3

[(not currently active) Ted Mielczarek]

Comment on attachment 290731 [details] [diff] [review]
set pref to 2 in firefox.js

Avoiding the minefield by setting it in firefox.js, nice.

Comment 4

[Mike Connor [:mconnor]]

Comment on attachment 290731 [details] [diff] [review]
set pref to 2 in firefox.js

pretty low risk, behaviour has been on for the searchbar for over a year, now making the paste behaviour the same for content

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 290731 [details] [diff] [review]
set pref to 2 in firefox.js

a=beltzner

Comment 6

[Kathleen :Brade]

My two cents:  I'd like to see eNewlinesReplaceWithSpaces or similar as a comment in the patch.  It really sucks having to track down places where people use integers rather than constants (and this is one of the places where you can't use it).  r=brade

Comment 7

[Mike Connor [:mconnor]]

fixed (didn't put the comments there, but I think we need a better place to put comments like that instead of in pref files that get parsed on startup)

Comment 8

[Reed Loden [:reed]]

Didn't you land this?

Comment 9

[Evan Parker]

To confirm, the fix for this bug should make it into M11 (beta 3), correct?  I'm a developer on Google Maps and we are *very* excited to see this fix for such a common user pain point!

Comment 10

[(not currently active) Ted Mielczarek]

Evan: yes, this will be in beta 3.

Comment 11

[Reed Loden [:reed]]

Resolving this as fixed, as per http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=/mozilla/browser/app/profile&command=DIFF_FRAMESET&file=firefox.js&rev2=1.245&rev1=1.244

Comment 12

[Jim Mathies [:jimm]]

Hey Mike - there are some comments in nsTextEditRules.cpp indicating the default for this pref should be 1 -

// 0. paste newlines intact
// 1. paste up to the first newline (default)
// 2. replace newlines with spaces
// 3. strip newlines
// 4. replace with commas
// 5. strip newlines and surrounding whitespace

Some folks in bug 432415 are curious why we chose this setting as the new default. Any ideas?

Comment 13

[Mike Connor [:mconnor]]

Because for the general case it is much more useful.  i.e. you can copy an address from a website and paste it into google maps.  That's the right (and backwards-compatible) default for the platform, but for us there's a big win from this.

Comment 14

[Evan Parker]

Setting the default to 2 is a big win for Google Maps and other mapping sites where users often try to copy/paste multi-line addresses into a search box.  Setting the default to 1 (the default in FF2) or 3 (as suggested in bug 432415) would break this use case.  Caveat: I am a developer on Google Maps, so I am obviously biased.

Comment 15

[Colin Cody]

(In reply to comment #13)
> Because for the general case it is much more useful.  i.e. you can copy an
> address from a website and paste it into google maps.  That's the right (and
> backwards-compatible) default for the platform, but for us there's a big win
> from this.

I might suggest it is "more useful" for one commercial enterprise - Google Maps.  Quietly changing the option #2 to the default takes what a user should have every right to expect with a cut & paste function, and then without explanation to the user, CHANGES THE CONTENT OF THE CUT and REPLACES newlines with ASCII 32 spaces   per the above: "replace newlines with spaces"

SUGGESTIONS:
The "shipped" default should be the defacto standard of #1.  The ability to change the default by the user should be made more user freindly.  Future upgrades should leave the user the option to have the upgrade honor the user selected default settings, and not overwrite them.

Comment 16

[Jesse Ruderman]

#1 "changes the content of the cut" too, by truncating it.  Arguably, that's a bigger change than replacing line breaks with spaces, and I can't think of any situations where it's more useful.

Comment 17

[Colin Cody]

When an application (for example, a user name field on a web page) is designed to limit user input to one line and only one line then, by definition, a CR or LF from a copy/paste should not allowed to be inserted.  That's what the application designer wants - to prohibit CR and LF.  Otherwise, the application designer could have allowed for multiple lines of user input.  It's the decision of the application, and it should not be the decision of the browser.

But to have a browser arbitrarily add ASCII 32 space(s) whenever an application prohibits ASCII 13/10  (CR/LF) is not an intuitively expected result of the cut and paste function - and is contrary to how millions of applications have been designed, written and used over many years.

Comment 18

[(not currently active) Ted Mielczarek]

This bug is closed. Further discussion here is not productive.