The default bug view has changed. See this FAQ.

set editor.singleLine.pasteNewlines to 2

RESOLVED FIXED in Firefox 3 beta3

Status

()

Firefox
General
P3
normal
RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: mconnor, Assigned: mconnor)

Tracking

Trunk
Firefox 3 beta3
Points:
---
Bug Flags:
wanted-firefox3 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

9 years ago
Created attachment 290731 [details] [diff] [review]
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.
Attachment #290731 - Flags: ui-review?(beltzner)
Attachment #290731 - Flags: review?(gavin.sharp)
Flags: wanted-firefox3+
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.
Attachment #290731 - Flags: ui-review?(beltzner) → ui-review+
(Assignee)

Updated

9 years ago
Attachment #290731 - Flags: review?(gavin.sharp) → review?(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.
Attachment #290731 - Flags: review?(ted.mielczarek) → review+
(Assignee)

Comment 4

9 years ago
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
Attachment #290731 - Flags: approval1.9?
Comment on attachment 290731 [details] [diff] [review]
set pref to 2 in firefox.js

a=beltzner
Attachment #290731 - Flags: approval1.9? → approval1.9+
Keywords: checkin-needed
Keywords: checkin-needed

Comment 6

9 years ago
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
(Assignee)

Comment 7

9 years ago
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)
Priority: -- → P3
Target Milestone: --- → Firefox 3 M11
Didn't you land this?

Comment 9

9 years ago
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
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Version: unspecified → Trunk

Updated

9 years ago
Depends on: 435704

Updated

9 years ago
No longer depends on: 435704

Comment 12

9 years ago
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?
(Assignee)

Comment 13

9 years ago
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

9 years ago
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

9 years ago
(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

9 years ago
#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

9 years ago
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.
Depends on: 432415

Updated

8 years ago
Blocks: 490713
No longer blocks: 490713
You need to log in before you can comment on or make changes to this bug.