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

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

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 on attachment 290731 [details] [diff] [review] set pref to 2 in firefox.js Avoiding the minefield by setting it in firefox.js, nice.

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 on attachment 290731 [details] [diff] [review] set pref to 2 in firefox.js a=beltzner

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

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)

Didn't you land this?

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!

Evan: yes, this will be in beta 3.

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

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?

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.

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.

(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.

#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.

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.

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