See bug 23485 for an agonizingly long discussion of the pros and cons of what text fields should do when the user pastes into them. 1. Windows truncates after the first newline. 2. Unix accepts the whole paste, newlines and all. 3. I don't know what Mac does. In case 2, we should also consider eliminating terminal newlines (see buster's point on 2000-08-31 09:41). Lots of people seem to feel strongly about this. It's not that difficult to offer multiple options and default them right on each platform.

Nominating for nsbeta3 consideration since people feel so strongly about it (read the arguments in bug 23485 for details on why).

Simon says Mac truncates at the first linebreak, like Windows.

see my comments in 23485

For the record: I don't feel strongly about it; the current implementation together with the behaviour of XPToolkit's single-line textedits is just buggy.

Fix checked in. The pref is "editor.singleLine.pasteNewlines", and the values are: // 0. paste newlines intact // 1. paste up to the first newline // 2. replace newlines with spaces // 3. strip newlines Unix default is 0, XP default is 1. Mac default *should* be 0 just like Unix, according to what mpt says in bug 23485, for compatibility with existing Mac text fields, but my Mac went south again and there are no Mac people around right now, so I didn't check that in. In the "paste intact" case, leading and trailing newlines are stripped, so that we don't see the problem that buster mentioned, since nobody wants that.

I guess I'll go ahead and mark it fixed even though I think the mac default should be different.

OK, but this changes nothing to the previous implementation on Unix, right? So, what do we do with the bugs I mentioned in the bug 23485?

Ben: it doesn't help with the problems you asked about in bug 23485 (no visual indication that there are other lines, up/downarrow not working to move between lines even though left/rightarrow do, etc). Those should probably be filed as separate bugs; the scrolling issue is something kin, buster, or mjudge might know something about, the "no visual indication" is something that needs a creative solution of some sort (I'd be just as qualified as anyone to take it, I guess).

OK, will comment in bug 23485.

Akkana, this is awesome. But Mac native single-line text fields accepting pasted new lines is a bug. And making our own widget set *surely* doesn't mean we have to emulate all the bugs in the native widget set! (We have enough bugs of our own ...) Like I said in bug 23485: If you can make it switchable per textfield, then XP default (including Mac) should be behavior 3 for the location field, and behavior 2 everywhere else. If you can't make it switchable per textfield, then XP default should be behavior 3 everywhere (since the majority of pastes into XPToolkit single-line textfields will be pastes into the location field in Mozilla Navigator).

> since the majority of pastes into XPToolkit > single-line textfields will be pastes into the location field in Mozilla > Navigator now, that's an assertion.

verified in 9/5 build.