23485 - browser window should strip newlines from url pastes

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect, P2)

Description

[Henrik Gemal]

If you take the text between the --- and copy and paste it into the Mozilla
location field you get this:
http://www.gemal.dk/ x
and the log says:
FindShortcut: in='http://www.gemal.dk/ x '  out='null'
Document http://www.gemal.dk/ x loaded successfully
Document: Done (11.1 secs)

---
http://www.gemal.dk/
x
---

Both in Netscape 4.7 and IE if you copy and paste the text between the ---
you'll get "http://www.gemal.dk/" nuthing more.

Comment 1

[Eli Goldberg]

Akkana, for your consideration.

---

$.02: I don't see what the bug is --- URLs can be split across two lines (e.g.
older mailing software may add a line break), and the fact that Nav 4.7 and IE
don't successfully put them back together doesn't mean that we should also fail
to do so.

Comment 2

[Akkana Peck]

I think this is a request that when a URL containing spaces or new lines is
pasted (or otherwise entered) into the url bar, we should only look at the part
up to the space and not the stuff after that.

I'm not sure what the policy is on this aspect of URL parsing, or whether this
is supposed to be handled by the browser window or by netlib.  Reassigning to
the browser group and cc'ing netlib people for comment.

Comment 3

[Warren Harris]

This is a weird one. On one hand you want to trim white space from the ends of
the text, but it it occurs in the middle, you might want to escape it. (On
the other hand, maybe that signifies an internet keyword search.) But CRs should
be handled differently altogether. I see that 4.x takes the first line when the
pasted text contains a CR.

Comment 4

[Andreas Otte]

Funny stuff, somewhere, someone is converting the 0x0a from the cut&paste into a
space, which is then converted into %20, at least with the new URLParser. Does
anyone know, who is doing the conversion? Best thing (I think) would be to just
remove all control characters (not spaces!!!) from a cut&paste into a one-line
texteditor.

Comment 5

[Jerry Baker]

Is this a dup of bug 22388?

Comment 6

[Andreas Otte]

The answer why we are seeing spaces instead of newlines can be found in bug
21032. How about removing newlines instead of replacing them with spaces?

CCing buster.

Comment 7

[buster]

there was some debate about what the operation ought to do.  The choices were:
1) terminate at the first newline (truncate the string)
2) convert newlines to spaces, so paste of a string like "hello\nworld" would
look right
3) drop newlines, as suggested here.

Clearly, 2 and 3 are at odds, and I think equally valid.

The coding is simple, the decision about what ought to happen is a bit harder.
My understanding is different platform's native widgets handle this differently.
I'd like to see a matrix of native controls on win/mac/linux.  WinNT truncates
(option 1).  cc'ing german, since this is primarily a UI/usability issue.  There
was some momentary temptation to let the page/app author decide, but I really
think that the resulting inconsistency is much worse than making a single
decision.  We could make it a pref, but that seems like overkill.

Comment 8

[Warren Harris]

Do what 4.x does, which is #1, above.

Comment 9

[buster]

warren, do you know if that's what 4.x does on all platforms, or is that just
what it does on windows?  I'm in NoCal, don't have anything except my windows
machine here with me today.

Comment 10

[Warren Harris]

I see that 4.61 on linux just removes the CR and pastes 2 urls in succession --
obviously the wrong thing to do since this will load neither URL and instead
will do a keyword search.

Mac does what Windows does.

Comment 11

[Andreas Otte]

But this "feature" helps alot when a URL is just broken into two or more parts
most probably by a linebreak mechanism.

Comment 12

[buster]

cc'ing akkana, who was one of the people involved in the original thread.

Comment 13

[buster]

assigning bug to german, we need a UI decision here.

Comment 14

[Akkana Peck]

The discussion so far has centered on what should happen in a paste to the url
bar.  But keep in mind that the url bar is not the only text field in the
product, so altering general text field behavior based on what a urlbar should
do (e.g. truncating after the first url) may not be the right solution.

Incidentally, some native text fields on Unix, including the Motif ones used in
4.x, will accept a newline as part of a paste (and this behavior is quite useful
in some contexts, like IRC clients).  So make that option 4 in Steve's list:

4. Accept newlines as a valid pasted character

The browser or netlib "go to url" code can then choose to terminate the string
at the newline, remove the newline and append the two strings (which would be
very useful in going to urls copied from mail clients like Eudora or OE which
break long URLs), or whatever.

Comment 15

[Warren Harris]

Andreas: This feature doesn't help much on unix either when the url is broken
across multiple lines because it puts in a space. You still have to go edit the
space out.

On a related note... I always found it frustrating on the Mac that if you
selected 2 or more html files and double-clicked them, the browser would end up
only displaying one of them. It neither opened separate windows for each html
file in the selection, nor did it stack all the files in the current window
such that go back would go to the other ones. Maybe these 2 things are related:
pasting multiple URLs in the location bar is like double-clicking multiple html
files in the finder. They should both open multiple windows. (Just an idea.)

Comment 16

[Andreas Otte]

warren: That's why my suggestion was to remove the newline not replace it by a
space.

On your related note: I find that idea very good, maybe it can be combined with
very smart code that detects well known URL delimiters and pastes broken up URLS
together and then opens a window for each resulting URL or stacks them in one
window.

Comment 17

[german]

I Akkana's option 4 (is it feasible in time): allow multiline pasting. 
Rationale: it is easier to fix extranous NL chars than loosing half the selected/
copied information. After all when the user selected this information, they 
wanted to have all of it copied.
But if URL bar would parse things in such a way that if it detects multiple well 
formed URLs, it would open multiple corresponding windows, as Warren suggests, 
this would be a very good thing. This last part would be independent of whether 
they are split by a newline char or not.
If we agree who is going to implement those two parts?

Comment 18

[Warren Harris]

First time I've heard 'Akkana' used as a verb, but hey, if she can make it 
happen... :-)

I know there's already code in mailnews for URL detection in text documents 
that compensates for line wrap, etc. An outside developer was working on that 
(forget who off hand -- Rich Pizzarro should know). Maybe that can be pulled 
out to determine the set of actual URL strings in the selection before pasting 
and/or creating multiple windows.

Comment 19

[buster]

option 4 won't happen in the first release without an act of god.  it's hard, 
and we don't have time for extra features now.  it's not in any UI or functional 
spec, it's just plain old fashioned feature creep.  there are simply more 
important things to do.
so:
1) truncate as windows and mac do today
2) map the newline to a space
3) just drop the newline?  
I vote for mapping the newline to a space, because it gives the best 
representation of what the user was trying to accomplish most the time, in a way 
that is recoverable when the guess is wrong.

also, any URL sniffing must be done totally independent of the editor paste 
code, with some sort of event handler unique to the url bar.

please, lets move this conversation to a newsgroup so more people get get 
involved.  I'll start if off by posting the comments to date.

Comment 20

[Warren Harris]

I think it's helpful to put suggestions in bug reports like this so that some 
ambitious person out there can understand the grand scheme and potentially 
implement it some day. If I put it in a newsgroup the suggestion will get lost.

Comment 21

[rhp (gone)]

Ben Bucksch is the one that took over the URL detection code.

- rhp

Comment 22

[buster]

I agree with you warren that it's useful to put suggestions in the bug report as 
well, but conversations in a bug report are restricted to those who know to look 
for it, where the newsgroups can bring in a broader audience.  I plan on copying 
the results of the newsgroup thread, if any, back into this bug.
Just trying to get as much data as possible before making a decision.

Comment 23

[Ben Bucksch (:BenB)]

warren,
Yes, there is code, that does nearly what you would want for the "option 4".

Some corrections:
- It is not mailnews specific and lives in netwerk
(<http://lxr.mozilla.org/seamonkey/source/netwerk/streamconv/converters/mozTXTToHTMLConv.h>)
- It does not compensate newlines, it just treats them like any other
whitespace.
- The reaction on whitespace depends on the delimiters
  - For "correct" URLs (following RFC2396's or RFC1793's recommondations, i.e.
<URL:scheme:foo>, <scheme:foo> or "scheme:foo" (quotes count)), whitespace is
stripped in the resulting URLs
  - For "freetext" URLs (i.e. delimited by whitespace at the start), the URL
ends at the first whitespace. (And <a
href="http://www.mozilla.orgIdon">http://www.mozilla.orgIdon</a> 't see a way to
avoid that.)

My code was written with HTML output in mind, so the output is currently with a
tags. However, I would just have to subclass mozHTMLToTXTConv and overwrite a
few functions (the actual number depends on the needed output format) to make it
suitable for the proposal here. The class also includes a completion function,
that way we can finally get rid of the hack in nsWebShell::LoadURL, too.

I see the collaboration that way:
1. The user pastes some text into the URL bar. This is done by generic TextEdit
code and should let multiple lines intact.
2. Some xpfe code notices the paste and passes it to a function of my new class.
3. This function tries to detect the URLs.
4. The xpfe code parses the output, loads the first URL and opens new windows
for possible additional URLs.

I volunteer for implementing 3.

Comment 24

[Akkana Peck]

Steve, can you explain why 4 is any harder than 2 or 3?  In all cases, you're
looping over characters, come to a newline, then either include it (4), map it
to something else (2), or omit it (3).  Doesn't seem like it would take any more
code.  Where does the difficulty come in -- is the multiline detection code
somehow tied to the presence of a newline and isn't smart enough to know that
it's only in a one-line text field?

Feel free to move your answer to a newsgroup, but please let us know which
newsgroup you think is most appropriate so we'll be sure to look for it there. 
(I haven't seen it yet, maybe I'm not caught up on the right newsgroups.)

Comment 25

[buster]

akkana: single line text controls don't display right when newlines are in the 
text stream.  they get vertical scroll bars.  This is independent of the 
"inappropriate vertical scrollbars in text controls" problem that kin is working 
on.  there is other code specific to newlines in single-line text controls also 
that would have to change.  it simply isn't worth the time as we try to clamp 
down for beta.

thread was posted to n.p.m.ui

Comment 26

[german]

I do not think this is a beta or even m14 candidate so barring any objections I 

will move that to m15.

Comment 27

[Jim Roskind]

Moving to M16 to facilitate M15 checkpoint stability branch.

Comment 28

[Mike]

M16 has been out for a while now, these bugs target milestones need to be 
updated.

Comment 29

[german]

what's the state on this bug? Can we do option 4 now? If not I IMO we should fall 
back to option 2 (newline to space). updating milestone to 18 for now

Comment 30

[Judson Valeski]

I haven't read the entire bug, just thought I'd add some input. I just copied a 
url from bugzilla that was cut across a line. When I pasted it into the url bar 
that newline had been replaced w/ a space so I had to go back over it and delete 
the space before loading. I havne't spent much time thinking about the problem, 
but at first glance I'd say newlines should not be converted to spaces, rather, 
they should just be removed from the string.

Comment 31

[Andreas Otte]

We should go with the removal of CRLF from the uri, do not convert to space.

Comment 32

[Akkana Peck]

Yes, we've always been able to do option 4 (and it's no harder for the user than
the space option we're doing now, since the user still has to go back and edit
out one character).

Ideally, if the paste included the newline, then the urlbar or browser window
(or netlib?) could remove the newline before passing the url off to netlib.  It
would be wrong to design general editor behavior based on what we want to happen
in one widget.

Shall I take this bug, and make the text field do the right thing (allow the
newlines), then pass it off to a browser (or netlib?) person to do the right
thing with the newlines?

Comment 33

[Andreas Otte]

The netlib part (removing CRLF) can happen in 

nsDocShell::CreateFixupURI(const PRUnichar* aStringURI, nsIURI** aURI)

where we already do a trim of spaces.

Comment 34

[Judson Valeski]

yea, I'm w/ akkana on this one. and andreas provides the point to do the 
conversion.

Comment 35

[german]

OK! Akkana take it from here...

Comment 36

[rubydoo123]

setting to nsbeta3+

Comment 37

[rubydoo123]

adding the brackets in the status

Comment 38

[rubydoo123]

setting priority in status whiteboard

Comment 39

[Gagan]

*** Bug 45953 has been marked as a duplicate of this bug. ***

Comment 40

[Akkana Peck]

Bumping up to P2 since the netlib part of this bug will also have to happen. 
(It should be easy, though.)

Comment 41

[Akkana Peck]

I have a fix for the editor side of this -- I know which line I need to change
to insert whatever we want to insert for single-line text areas.

It turns out that if we insert an actual newline, it doesn't show up as a CR
glyph -- instead, gecko shows only the last line of pasted text, so it looks
like the rest was lost.  Maybe that's okay; but an alternate suggestion is to
map it to the sequence "\n".  (No, non-developers won't understand this, but
would it be any less understandable than not seeing anything but the last
line?)  Then the urlbar could look for the sequence \n (\ is an illegal
character in URLs, isn't it?) and edit it out before going to the url.

Opinions?  I can do either one, whichever seems like it would be less confusing
for the user.

Comment 42

[Ben Bucksch (:BenB)]

Akk, why not just ap it to space? For URLs in freetext, there's no difference
between any kind of whitespace.

Comment 43

[Akkana Peck]

Because text controls are used in a lot more places than the URLbar, and in some
of them it's handy to be able to paste newlines; and in the urlbar, you can't
just edit out all spaces, since some urls do have spaces in them.

Comment 44

[Daniel Bratell]

Users write paths to local directories in the urlbar too, and on Windows they do 
contain \ so it's no good special char.

Comment 45

[Blake Ross]

akk: fixed?

Comment 46

[Akkana Peck]

Fixed.  We paste the real newline.  Since text fields aren't scrollable, this
means you'll initially only see the stuff after the last newline (if you're
looking closely, you'll see the rest flash as it gets inserted); but if you then
hit return in the urlbar, the newlines will be removed and the url is loaded
correctly.

This does no removal of spaces or other characters, only newlines.

Comment 47

[Ben Bucksch (:BenB)]

So, you're loading another URL (possibly even another server) than you see
before you trigger the load? That is bad. Sorry, REOPENing.

Comment 48

[Akkana Peck]

You're opening the url that you pasted.  There's no way (that I could come up
with) to display the fact that a url has embedded newlines.  If you want such a
display, open a separate bug on it and cc me (you can even assign it to me if
you want, but it'll probably get low priority).  Some fonts have a special glyph
for the ^M and ^J characters, and some text field implementations (like the one
I use in tkirc) use that glyph to show when a text field has embedded newlines,
so if someone wants to go into font/rendering code and choose a glyph, we could
switch to that.  I know where to make the changes now.  Meanwhile, this
implements the functionality that was asked for in the bug.

Comment 49

[Ben Bucksch (:BenB)]

When *pasting* in the urlbar (not generic texfields), I would either strip
newlines or replace them with spaces.

Comment 50

[Akkana Peck]

Paste currently happens at a lower level, in the editor, which has no idea
whether it's a urlbar (or even what a urlbar is).  One could intercept that from
the menu-based paste, since that goes through the browser window controller, and
write something that intercepted middle-mouse clicks to handle middle-mouse
paste and do the same thing.  That "same thing" would have to be to strip
newlines -- replacing them with spaces still leaves the user with a url that
doesn't work unless it's edited.  We want to make this easy, so you can paste
and hit return and have it "just work".

Comment 51

[Ben Bucksch (:BenB)]

Oh, didn't relize that it was so hard to intercept a "paste".

Comment 52

[Stephen Koren]

vrfy fixed

Comment 53

[Blake Ross]

In a build I just pulled, copying the original text and pasting it pastes
exactly that text into the URL bar, linefeeds and all.  Is this correct?  If so,
how?  The URL bar can't be multiline, that's _very_ confusing.  What's the
proper behavior so QA can verify?

Comment 54

[Matthew T (active 1999-2002)]

Looks like a wide range of opinions here, so `correct behavior' is debatable.

There seem to be a bunch of people here who think pasting newlines into a
single-line field should be possible. To which I can only say: if it's not 
possible to enter them directly, why should it be possible to enter them by 
pasting? That makes no sense.

FWIW, I've been in Web chat rooms where 4.x's habit of allowing pasted newlines 
to be inserted in a single-line field has stuffed up the entire chat. If you want 
to allow pasted newlines in Chatzilla, then just give Chatzilla a button to 
toggle the text field between a single line and multiple lines -- don't introduce 
confusing behavior into the whole world of XPToolkit instead.

The perfect solution would be to distinguish between pasting into the location 
field, and pasting into any other text field. So you would delete newlines during 
a paste into the location field, but convert them to spaces in any other field.

However, apparently you can't do that right now, so you need a single solution. 
It seems to me that by far the most common occurrence of this situation will be 
pasting a long URL (with newline in the middle) into the location field, e.g.
----
http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-
209.html#HEADING209-8
----
... so the most useful single behavior would be to just strip newlines when they 
are pasted into any single-line text field.

Comment 55

[Henrik Gemal]

This is not fixed. Having multiple partly hidden lines in the Location field is 
no OK.

Comment 56

[Akkana Peck]

Re-closing.  I fixed it according to the most recent agreement in the bug, and
the functionality works.

Comment 57

[Henrik Gemal]

"agreement" ?
As a normal user I simple understand *nothing* of whats going on when pasting a 
"multiline" url into the Location field.

Comment 58

[Blake Ross]

Sorry (I know what it's like to fix a bug and have people complain and want it 
fixed differently), but I also don't think that pasting the newlines into the 
URL bar is the solution.  It's awful and inconsistent because, as Matthew said, 
you can only paste paste multiple lines, but not type them. 

And consider this: a user copies and pastes an URL with multiples lines (like 
the original example given), then decides not to go there after all, so she 
deletes what's in the URL bar (which is the part of the URL from the last 
newline to th end of the URL) and types where she really wants to go.  But it 
won't work, because the the other part of the original URL still remains in the 
URL bar, just not visible (you have to drag-select with the mouse to see it).  
This is _very_ confusing to the user.

Comment 59

[Akkana Peck]

I'm removing the nsbeta3+ part of this bug, since I've fixed it in the way I
said I would, which, at the time, Jud, Ben, and German all agreed was okay, and
which is what NS4.x does on Unix (except that it displays it differently, in a
way Gecko probably can't).

It's not that hard to intercept pastes in the browser window, though it may have
to be done in a couple different places (for menu vs middlemouse paste; I
haven't looked to see how the code is factored).

If everybody feels so strongly about this, why doesn't someone make a patch?  It
could probably all be done in JS, just like middlemouse paste was.  But if you
want me to do this, convince the powers-that-be that it's more important than my
other bugs and needs to be +'ed.

Comment 60

[Ben Bucksch (:BenB)]

OK, I read over the bug again, updated my Mozilla build and tried it out. Akk,
I'm sorry for objecting to your fix and reopening this bug. Yes, back in
January, I indeed agreed to the solution you implemented, and it again seems to
me to be the best solution.

The problem is Gecko's single-line text edit.

Additional Comments From [e-mail] 2000-01-27 10:59:
> single line text controls don't display right when newlines are in the 
> text stream.  they get vertical scroll bars.

huh? Vertical scrollbars are what I would expect for multiple line in a single
line textedit, i.e. for me, a single line textedit is just a multiline one with
height 1.

So, if the user pasts newlines, e.g. in the urlbar or in chatzilla, (s)he can
see this fact, and relatively easily navigate through the text to fix it (for
chatzilla, this sometimes means removing newlines, sometimes leaving them
intact, but editing the first line etc.)

Right now, it is completely broken:
- No visual indication for more half of the content
- caret-up doesn't work, but home/caret-left does move to the previous line.
*Very* irritating.
- caret-down moves the caret one line down *on the screen* (i.e. it is under the
textedit field!) to the position where the second line would end, if it where a
2-line textarea.

Is there a bug filed about this?

> thread was posted to n.p.m.ui

<http://x59.deja.com/%5BST_rn=fs%5D/threadmsg_ct.xp?AN=579778879.1&mhitnum=2&CONTEXT=967696862.807534632>

Summary: I (again) agree with the solution, but it exposes an XPToolkit bug. I
suggest marking this bug fixed.

Comment 61

[Blake Ross]

No.  Single-line textboxes are just that -- single-line.  They're not just made 
to *look* like they only support one line, they really *should* only support 
one line (else it would be deceiving to the user).

From the Windows User Experience Guidelines: "A textbox is a rectangular 
control where the user enters or edits text.  It can be defined to support a 
single line or multiple lines of text. [...] Horizontal scrolling is available 
for single-line text boxes, and horizontal and vertical scroll bars are 
supported for multiple-line text boxes."

Comment 62

[Matthew T (active 1999-2002)]

Vertical scrollbars for a single-line text field would make it look not like a 
multi-line text field, but like a spinbox (i.e. click up/down to
increment/decrement the value in the text field).

> If everybody feels so strongly about this, why doesn't someone make a patch?

Helpwanted ...

Comment 63

[buster]

this might well be a platform difference, one that is important to respect.
on windows, there is no precedence that I know of for single-line edit controls 
accepting multiple lines of content.  Windows single-line edit controls *really* 
mean "one line"...everything after a newline on the clipboard is truncated on 
paste.  anything else would be confusing to a typical user, especially with the 
lack of visual feedback.

can someone comment on the Mac standard in this area? (cc'd simon, my favorite 
Mac spokesperson.)

so presumably you could check the nsILookAndFeel to get the default behavior, 
and if you really want to do extra work add a pref that could override this for 
folks who want a different platforms' semantics.

but I have to ask, is this really a nsbeta3+ issue?  It seems to be sucking a 
lot of resources, and I don't see that it's been approved.

Comment 64

[buster]

it's worse than just a platform difference, it's a real usability problem on 
windows.  example I just ran across:  I selected some text from the browser and 
pasted it into the URL bar.  It showed up for an instant, then disappeared.  
Why?  Because unknowingly, the selection included a trailing newline.  Normally, 
this would be a non-issue.  So the solution of "seeing the stuff after the last 
newline" means this looks like a real bug in our product to windows users, who 
will see an empty URL field.  In plenty of applications, it's unclear when the 
trailing newline will be part of the selection for a copy.  In the "single line 
control means single line" implementation, this distinction isn't an issue.

I know it must be frustrating to have written the code only to get complaints.  
But it isn't useable as-is on Windows.  I really think there needs to be a 
platform switch for the default behavior for this, or if time runs short simply 
go back to a simpler solution where newlines are either dropped, converted 
to spaces, or cause a truncation.

Comment 65

[Simon Fraser [no longer active]]

Yup, Mac truncates the line at the first linebreak, and I think it's reasonable 
for us to do this also.

Comment 66

[Akkana Peck]

That's a good point about the trailing newline.

It sounds like
1. we ought to have switchable behavior as to whether you can paste multiple
lines into a text field, and
2. we ought to have a handler for paste in the browser window which intercepts
the paste before it gets to the text field, so even on platforms where you can't
do multiline paste, it works anyway.

These are two separate bugs, really.  So I've filed bug 50935 on "Multiline
paste in text field should be switchable", and I'm changing the summary of this
one to reflect what needs to be done here.

I was going to cc everybody here on bug 50935, but there no longer sees to be a
way to copy anything from a bugzilla cc list, so those of you who are interested
will have to add yourselves.

I don't have a problem with doing the work for either or both of these bugs, and
neither one would take all that long (a day or two for both of them) but someone
will have to argue them through PDT so that I'm allowed to work on them and
check in the fixes.

Comment 67

[rubydoo123]

I agree with buster on this one, Akkana, please follow the guidelines as 
mentioned in your 8-31 comment:
1. make it switchable based on os
2. for win & mac, truncate at newline on paste into <input type=text>
3. for linux, allow multi-line into <input type=text>

Comment 68

[Matthew T (active 1999-2002)]

Contrary to what Simon says, Mac OS (I've tried this on 8.6 and 9.0) does allow 
you to paste newline characters into a single-line text field; navigating across 
a newline with the Left/Right keys hides the current line and shows the
previous/next line. But I've always considered that to be a bug in the Mac OS 
text control (it's not the only bug in that control). Bugzilla itself removed the 
newlines when I pasted them into the status field just before; the Web chat room 
I mentioned earlier didn't, with unfavorable results. We can't expect
non-paranoid CGI scripts (for example) to handle newlines in data properly, when 
they *explicitly* asked the client for a single line of text.

If you're going to make the text field switchable in this behavior, that's great; 
but it shouldn't be for the purpose of differentiating between platforms, it 
should be for the purpose of differentiating between the location field (strip 
newline characters) and every other text field (convert newline to spaces). If 
Beth's recommended behavior is implemented, then I *still* won't be able to paste
----
http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-
209.html#HEADING209-8
----
into the location field and get the desired result -- on any platform. All I'll 
get is a 404 error.

Comment 69

[Akkana Peck]

Matthew: that's useful information about the Mac default, but probably should
have been made in bug 50935, since that's the one covering making text field
behavior configurable.  I just checked in a fix for that bug, but made the mac
default the same as windows, which seems wrong (we should copy what real mac
text fields do) according to what you say. 

As for this bug, it turns out to be harder than I thought: I haven't figured out
how to intercept middle-mouse paste, and even for menu-based paste will probably
have to add a paste handler to the browser window controller (wherever that
lives).  For now, anyone wanting the behavior in this bug (multiline url paste)
can get it by turning on 
user_pref("editor.singleLine.pasteNewlines", 0);

I've added a guard to eliminate leading and trailing newlines so we won't see
the problem buster described.

Comment 70

[Ben Bucksch (:BenB)]

With the solution for bug 50935, there's still the possibility of multiple lines
in a single-line textedit field. So, the following problems still remain:

> Right now, it is completely broken:
> - No visual indication for more half of the content

What should we do about that? Who should get this bug?

> - caret-up doesn't work, but home/caret-left does move to the previous line.
> *Very* irritating.
> - caret-down moves the caret one line down *on the screen* (i.e. it is under
> the textedit field!) to the position where the second line would end, if it
> where a 2-line textarea.

Filed bug 51121.

Comment 71

[rubydoo123]

Akkana -- what is the current state of this bug? What needs to be done here?

Comment 72

[Warren Harris]

I agree with Matthew -- I want newlines to be stripped so that urls that have 
been broken across lines will still load.

I don't see why we would want different behavior on different platforms, nor do 
I see why we would want any fancy multi-line editing.

Comment 73

[rubydoo123]

at this point, 6.0 is functioning as 4.x, any additional work is deemed as new 
feature, we cannot afford to have feature creep at this stage. Moving this to 
future, we will readdress this after RTM

Comment 74

[don]

*** Bug 57031 has been marked as a duplicate of this bug. ***

Comment 75

[Jesse Ruderman]

*** Bug 39258 has been marked as a duplicate of this bug. ***

Comment 76

[Jesse Ruderman]

*** Bug 67319 has been marked as a duplicate of this bug. ***

Comment 77

[rubydoo123]

talked with akkana on this one, reassigning to browser team

Comment 78

[Asa Dotzler [:asa]]

apps maybe?

Comment 79

[Chris McAfee]

Over to akkana for a look, not clear what needs to happen here.
If we should strip out CR as warren says in 9/6/00 comment,
please bounce back to xpapps.

Comment 80

[Akkana Peck]

Yes, newlines should be stripped as per warren's comment.  That's a urlbar and
browser window specific thing, not something that should happen in general in
text fields (it already does work on Unix, but Mac and Windows people wanted
different behavior on multiline paste to single line text fields).

Back to apps ...

Comment 81

[sairuh (rarely reading bugmail)]

->url bar, perhaps? feel free to punt back to xp apps...

clearing milestone, nominating for moz0.9. [i know, it's an enhancement,
but...just wondering if it's possible.]

Comment 82

[Boris Zbarsky [:bzbarsky]]

see bug 72659 for a similar request for the open location dialog

Comment 83

[John Morrison]

*** Bug 72659 has been marked as a duplicate of this bug. ***

Comment 84

[Asa Dotzler [:asa]]

*** Bug 77932 has been marked as a duplicate of this bug. ***

Comment 85

[Viswanath Ramachandran]

nav pretriage: recommend nsbeta1-, Future. 

Comment 86

[Paul Chen]

nav triage team:

Marking as per Vishy's pretriage comments. nsbeta1- and future

Comment 87

[Chad Austin]

*** Bug 81963 has been marked as a duplicate of this bug. ***

Comment 88

[Chad Austin]

Another annoying situation I ran into...  If you copy a single URL from another 
program, but it starts with a newline (i.e. "\nhttp://aegisknight.org"), it 
doesn't show up in Mozilla at all.

Comment 89

[Chris McAfee]

sorry I didn't get to this.  Over to vishy to find an owner.

Comment 90

[Henrik Gemal]

would it really be a lot of work just to strip a newlines? To me this is one of 
the reason why I use IE. I hate having to open a additional texteditor app just 
to strip the newlines to load my copy-text-site-URL...

Comment 91

[Andreas Otte]

We strip newlines from urls in necko. If that is not happening please give some
examples.

Comment 92

[Andrew Thompson]

This is a user interface issue. 

Type the following into a text editor (eg, Notepad)

http://www.
mozilla.org

Now select those two lines and paste into the adress bar in Mozilla.

What you see:
http://www.

What we'd like to see:
http://www.mozilla.org

Obviously the example above is bogus, but *many* email clients, including
outlook, and indeed also Bugzilla, wrap long URLs using newlines. Copying and
pasting these into Mozilla is a real pain at the moment.

Comment 93

[Akkana Peck]

It's true, netlib does strip the newlines.  With the pref
"editor.singleLine.pasteNewlines" set to 0 (the linux default), I only see
what's before the newline, but since the text field actually contains the whole
url, it gets passed to netlib and the url is loaded correctly.  It's still not
displayed correctly, though, and win/mac users use a different default setting
for the default, so this bug is still quite valid: we ought to strip the
newlines at the UI level so the url is displayed correctly and loaded correctly
on all platforms.

Comment 94

[R.K.Aa.]

*** Bug 114530 has been marked as a duplicate of this bug. ***

Comment 95

[Peter Trudelle]

->hewitt, p3/moz1.0.  Joe, please fix this by stripping newlines from pasted
URLbar text.  If anyone wants to discuss this, please do so in n.p.m.browser,
not here.

Comment 96

[Peter Trudelle]

*** Bug 121291 has been marked as a duplicate of this bug. ***

Comment 97

[Ben Bucksch (:BenB)]

re comment 18 and comment 23:
I now filed bug 116242 about that URL-finding function, partly with this bug in
mind. If you plan to fix this bug that way (which I suggest), I will give that
bug a much higher priority.
(Posting that here, not in the newsgroup, because of comment 20.)

Comment 98

[rubydoo123]

removing myself from the cc list

Comment 99

[Peter Trudelle]

I think this is wfm; current behavior matches IE6, Opera 6, NS 4.x, Word,
Excel, and most other apps, and is probably as designed. cc UE for input, please
reopen if otherwise.

Comment 100

[Jesse Ruderman]

Trudelle: this bug has several dups, and fixing it would make it much easier to
paste wrapped URLs from e-mails and web forums (which often must hard-wrap text
to avoid expanding the page).  Please give a reason if you want to wontfix it.

Comment 101

[Jesse Ruderman]

http://makeashorterlink.com/.  You can be pretty sure users find a bug annoying 
when one of them creates a web site to work around the bug.

Comment 102

[Jesse Ruderman]

*** Bug 134939 has been marked as a duplicate of this bug. ***

Comment 103

[Vadim Berezniker]

*** Bug 136724 has been marked as a duplicate of this bug. ***

Comment 104

[Gilles Durys]

*** Bug 137391 has been marked as a duplicate of this bug. ***

Comment 105

[Kevin Chen]

*** Bug 164428 has been marked as a duplicate of this bug. ***

Comment 106

[Jesse Ruderman]

Fixed in Chimera (bug 160132).

Comment 107

[André Dahlqvist]

*** Bug 177503 has been marked as a duplicate of this bug. ***

Comment 108

[Olav Vitters]

*** Bug 183984 has been marked as a duplicate of this bug. ***

Comment 109

[Daniel Clemente]

Should the summary be changed to include also INPUT form controls? (see bug 187785)

Comment 110

[Jesse Ruderman]

#9 on Jakob Nielsen's "Top Ten Web-Design Mistakes of 2002" is "URL > 75
Characters: Long URLs break the Web's social navigation because they make it
virtually impossible to email a friend a recommendation to visit a Web page."
(http://www.useit.com/alertbox/20021223.html)

Comment 111

[JoSH Lehan]

I strongly recommend also deleting leading and trailing whitespace from the
pasted URL!

There is no need to have leading and trailing whitespace in a URL.  Deleting
that whitespace would make it easier for the user to cut and paste.  It is very
easy to accidentally select nearby blank lines and end-of-line markers when
selecting a large block of text.

As an example, try cutting and pasting a line of text that has a leading newline
(a common mistake new users make when they drag the mouse too far).  It will
paste into Mozilla's URL bar as a completely blank line, because of the leading
newline!

Comment 112

[David G King]

*** Bug 136741 has been marked as a duplicate of this bug. ***

Comment 113

[Tony Tovar]

hmm, well, now that my RFE has been dupe'd to this bug, let me suggest the
following for parsing URL input:
- try to identify/eliminate obviously invalid leading chars,
 . protocols, e.g. "check this out: http://"
 . generic 'www' servers (with a leading space?), e.g. "check this out: www."
- make this a priority!  It's such an obvious ease-of-use feature, i.e., to not
need to use a text editor to 'fix' URLs copied from email...

Also, if this was, in fact, fixed on Chimera/Mac back in Oct '02 (comment 106),
why wasn't it fixed on Windows?  Don't worry, I'm adding my vote to this bug and
urging the people who voted for mine to change to this one!

Comment 114

[David G King]

It was fixed in Chimera. However the files that were patched don't exist in the
"main" Mozilla tree. However, the code in that patch could be reused in the
appropriate file with minimal chnages.

Comment 115

[Scott Gifford]

This bug seems to be fixed in Firebird 20030903 on Linux.  Anybody still seeing
it on other platforms?

Comment 116

[Akkana Peck]

sgifford: Linux has done the right thing since comment 46, because it has
different text field behavior from the other platforms.  Other platforms can
work around it by using the pref described in bug 50935 to get the current linux
behavior, but a correct fix should apply only to the urlbar and not require
changing behavior of all text fields.

Comment 117

[Bob Firth]

*** Bug 221129 has been marked as a duplicate of this bug. ***

Comment 118

[Olivier Cahagne]

*** Bug 229254 has been marked as a duplicate of this bug. ***

Comment 119

[Daniel Wang]

original problem described in bug description resolved -> fixed

Jesse Ruderman, if there is any lingering problem, please file a new bug or
reopen the appropriate bug.

Comment 120

[Tony Tovar]

using Firebird 2004-01-27 on WinXP, pasting a URL with a [CR] in the middle
still results in only the first half of the URL being used.  Everything after
the [CR] is ignored.

I'm confused about several things here:
1. What is the expected behaviour?  Is Bug 77932 saying that text after a [CR]
should be ignored?
2. If the text is supposed to be ignored, how do we request an exception for
instances where email has a long wrapped URL?  Should we un-dupe and re-open my
RFE in bug 136741 ?

Comment 121

[R.K.Aa.]

*** Bug 237004 has been marked as a duplicate of this bug. ***

Comment 122

[R.K.Aa.]

*** Bug 238843 has been marked as a duplicate of this bug. ***

Comment 123

[Hermann Schwab]

WFM Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7b) Gecko/20040324
WFM Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7b) Gecko/20040314 Firefox/0.8.0+

with a changing a pref in about:config

editor.singleLine.pasteNewlines user set integer 3

Comment 124

[Tony Tovar]

Great!  The change to "editor.singleLine.pasteNewlines=3" worked for me, too, in
both Mozilla 2004-03-01 and Firefox 0.8 on WinXP.

Now the questions are:

1. when was this option added?
2. why isn't "3" the default setting?

Comment 125

[Asa Dotzler [:asa]]

*** Bug 162710 has been marked as a duplicate of this bug. ***

Comment 126

[Wayne Woods]

This bug is truly annoying, as I paste wrapped URLs on a regular basis. The
current assignee is gone, so I'll reset it.

Comment 127

[logan]

*** Bug 246912 has been marked as a duplicate of this bug. ***

Comment 128

[noys]

There are symptoms of this issue here that I do not believe (correct
me if I am wrong) this discussion has touched on as yet:

1- If the multiline URL is allowed, line 2+ of the URL remains when
you click back in the address bar, and enter in a new URL. i.e.:
Paste the URL:
http://www.siteA.com/
aaaaaaaaaaaaaaaaaaaa/
bbbbbbbbbbbbbbbbbbbbb

When you select the Address bar, and type over the last URL you had
with http://siteB.org you actually get the following URL evaluated:

http://siteB.org
aaaaaaaaaaaaaaaaaaaa/
bbbbbbbbbbbbbbbbbbbbb

So the users experience is interferred with.

The only way to get rid of it is to perform a 'press and hold delete'
while the URL clears out one char at a time...

2- There is a possiblilty that this might be used in phishing scams.
For example you might be able to prevent a user from seeing a
URL Proxy.

Although not as severe as other URL obfuscation issues, history has
shown that when used in combination, it may have an effect greater
than that initially assumed. For example, if you have a site with a
proxy CGI (like anonimyser.com) you can send a surfer to one site, while telling
them they are on another.  Paste the following URL in, and you see
anonimyser.com, and not google.com (for the sake of example, ignore the
anonymiser.com HTML header & Footer) 

http://www.anonymizer.com/
http://www.google.com

I know this would require a poorly created "proxy" site to work, but the tools
to set it up should probably not be a 'feature' of the clients browser.  There
may also be other ways to exploit this bug.  There are others out there who are
much better versed at dreaming up exploit scenarios for these types of things
than I...

Comment 129

[Tony Tovar]

I think you make a good point about the possibility of phishing but the fault
there lies in the current implementation of this feature, not the feature in
general.  For instance, if I paste this link:

http://www.goodsite.com/
http://www.badsite.com

the code currently shows only the first line.  How it treats a 2nd http:// is
unknown to me.  Ideally, I would expect Mozilla to display/interpret it as:

http://www.goodsite.com/http/www.badsite.com

In this case, not only is the 2nd line visible but it also can't be used to
obfuscate the actual base-URL.
________________

On a related note, everytime I've tried to test this, Mozilla (Firefox 0.8 was
most recent?) would interpret the line-break as %20 or something -- it did not
link the two lines correctly.  The complete URL was there but I had to wait for
it err-out and then manually correct the 'join'.

Comment 130

[Matthieu MOY]

Pasting

http://goodsite.com
.badsite.com/

Brings me to http://goodsite.com.badsite.com/ while displaying
http://goodsite.com ...

Comment 131

[Akkana Peck]

Attachment: Patch for discussion: reset urlbar if it changed after loadURI

Here is a very small patch which seems to fix the spoofing problem.

In navigator.js, after any time LoadURI is called, if the current URI is
different from the one we passed in, change the urlbar to show the real uri.

The question is why we weren't doing that already.  Are there cases where we
would NOT want to show the true url after loading?

Comment 132

[Daniel Wang]

> reset urlbar if it changed after loadURI
don't we have that already? Pasting
http://www.google.com/search?hl=en&ie=UTF-8&q=MOZILLA&btnI=I%27m+Feeling+Lucky
in the location, and it changes to mozilla.org on redirect.

> The question is why we weren't doing that already.
are you referring to multiple 40x HTTP redirects?

Comment 133

[Akkana Peck]

Daniel: see comment 130.  No, we don't put the fixed up uri back into the
urlbar.  That's what the spoofing discussion is about.

Comment 134

[Daniel Wang]

comment 130 works for me
> Pasting
>   http://goodsite.com
>  .badsite.com/
> Brings me to http://goodsite.com.badsite.com/ while displaying
> http://goodsite.com ...

Pasting "http://goodsite.com.\nbadsite.com/" sends me to 
"http://goodsite.com.badsite.com/". I think Matthieu is confused because the
goodsite.com.badsite.com/ does read "goodsite.com" in its content.

Comment 135

[R.K.Aa.]

*** Bug 250603 has been marked as a duplicate of this bug. ***

Comment 136

[Chris Vance]

(In reply to comment #123)
> with a changing a pref in about:config
> 
> editor.singleLine.pasteNewlines user set integer 3

If this pref is not changed, and left at the default of 1, copying and pasting
the following text:

"
http://www.url"
(with the newline at the beginning of the copied URL, and without the quotes)

...loads the correct URL, shows the favicon if it exists (only in Firefox), and
hides the URL being displayed.  The URL still exists in the Location Bar --
place the cursor in the bar and start typing.  The URL will then be shown with
the random typed text.

See on Windows XP SP2 in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040817
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040817
Firefox/0.9.1+

This hidden URL is not necessarily discussed in this bug, but related enough
that I wanted input before posting a possible dupe of the behavior discussed in
the present bug.

Shall I post a new bug documenting the hidden URL behavior?

Comment 137

[Akkana Peck]

My patch to this bug was for the problem of displaying something other than the
site we're on.  But no one seemed interested so I haven't pursued getting it
reviewed.

Technically yes, the hidden url is a separate bug.  But there's probably no
point in filing a new one unless there's some reason to (e.g. if you want to
argue for it as a security bug or something).  If you do file one, please cc me
and I'll attach my patch there.

Comment 138

[Daniel Veditz [:dveditz]]

The recent fix for bug 249322 fixed the URL display problem, pretty much along
the lines of akkana's patch except that single-line edit boxes won't replace
text if the new text differs from the existing text only by stripping new-line
characters.

Is there any other reason this bug is left open?

Comment 139

[Hermann Schwab]

*** Bug 264726 has been marked as a duplicate of this bug. ***

Comment 140

[Tony Tovar]

using Firefox 1.0-PR on WinXP, WFM !  When did this get fixed, though?  I must
not've been paying close enough attention because I don't remember anyone
saying, "I fixed it, try it now!"

Comment 141

[Phil Ringnalda (:philor)]

*** Bug 269200 has been marked as a duplicate of this bug. ***

Comment 142

[Wayne Woods]

It's still broken for me. A paste of two lines only pastes up to the first newline.

I'm using trunk nightly 20041109, so maybe it was only fixed on the Aviary branch.

Comment 143

[Martin Pool]

"editor.singleLine.pasteNewlines=3" works for me, and fixes what I consider an
substantial usability problem.  I can now just mark text and paste it, without
needing to clean up newlines by hand.  I must have cleaned them up a hundred
times in the last few years, and I've never wanted a newline in a URL or
single-line textbox.

Is there any reason why this behaviour cannot be the default?

Comment 144

[timeless]

"http://dcu.com
:[e-mail]"

where badsite is configured to require auth (over http).

Comment 145

[JoSH Lehan]

It still would be a huge ease-of-use improvement for Mozilla to automatically
clean up newlines (and other whitespace) pasted into the URL bar by the user.

The situation described in comment 144 would be best solved by a loud warning
box that appears whenever the user tries to load a URL that has a login and/or
password embedded directly into the URL.  If the URL looks normal and doesn't
have this, then just load it normally.

The usage scenario of trying to paste in a URL from email (broken into multiple
lines) occurs MUCH more often than the usage scenario of trying to trick a
victim into clicking on a false URL padded with newlines.

BTW, in the warning box, the user should see the URL broken down into its
components, printed on separate lines: user, password, site, path.  If they
agree to this, they could hit OK to load the site.  The usage of embedding a
login/password into the URL is mainly used for phishing and other bad purposes
these days, and if a user actually has a good reason for using them at a site, a
config preferences option could be set to bypass the warning box.

Comment 146

[Matthieu MOY]

> loud warning box that appears whenever the user tries to load a
> URL that has a login and/or password embedded directly into the URL.

This is already the case in Mozilla and Firefox

Comment 147

[JoSH Lehan]

About comment 146: Great!  If such a dialog box already exists, then this would
mitigate the danger of the user falling for a phishing scheme by clicking a URL
that was sneakily wrapped over several lines.

Since this warning feature already evidently exists and is on by default, then
there shouldn't be that much of a problem with making
editor.singleLine.pasteNewlines=3 the default behaviour (enabling "smart"
handling of newlines and other whitespace).

Comment 148

[Chris Vance]

(In reply to comment #147)
> About comment 146: Great!  If such a dialog box already exists, then this would
> mitigate the danger of the user falling for a phishing scheme by clicking a URL
> that was sneakily wrapped over several lines.

See the dialog that shows up by visiting http://username:[e-mail]/

This is on by default in both Seamonkey and Firefox.

> Since this warning feature already evidently exists and is on by default, then
> there shouldn't be that much of a problem with making
> editor.singleLine.pasteNewlines=3 the default behaviour (enabling "smart"
> handling of newlines and other whitespace).

I'd agree that smart handling of newlines is best for the location bar.  What
other spots in the UI or forms could this mess up?  Single-line edit boxes, for
instance?  I am not sure how removing the newline character would break anything.

Comment 149

[Wayne Woods]

A more recent comment on Mac OS X behaviour:
Apple's Safari browser strips out newlines, doesn't truncate the text, and
doesn't convert the newlines to pastes. So if you paste "a\nb" into the location
bar, it becomes "ab".

While the behaviour of Safari doesn't necessarily indicate a mandate of the
Apple HIG, it's a good guide. I think it's a compelling case for implementing
this behaviour in the Mac version of the browser, at least.

And since it doesn't leave newlines in the location field (and only deals with
pasted links, not embedded urls) I don't see any phishing issues.

As a side note, will this bug cover Firefox as well? Or is the location bar code
handled separately in Firefox?

Comment 150

[Wayne Woods]

Um, in my last post, "doesn't convert newlines to pastes" should have read
"doesn't convert newlines to whitespaces". Sorry.

Comment 151

[Frank Wein [:mcsmurf]]

*** Bug 294527 has been marked as a duplicate of this bug. ***

Comment 152

[tylernt]

If you have just encountered this bug and don't want to spend half an hour
reading all the above comments, just type about:config into your Address Bar and
hit Enter. Then find editor.singleline.pastenewlines and set the value to 3
instead of 1. This enables intelligent CR+LF paste handling instead of the
default, which is a unpleasant on Windows and perhaps other platforms. May I
suggest that 3 become the default for future versions, at least for Windows?

Comment 153

[Adam Guthrie]

*** Bug 299827 has been marked as a duplicate of this bug. ***

Comment 154

[Dave Townsend [:mossop]]

*** Bug 302491 has been marked as a duplicate of this bug. ***

Comment 155

[Dwayne C. Litzenberger]

Agreed.  I can't think of a scenario where it's _not_ a bug to accept multiple
lines of input in a single-line text field, on any platform.

IMHO, it is a bug for any UI using a single-line widget to expect users to enter
newlines into it.  (Right now, users can't type a newline directly into such a
widget anyway.)  Allowing newlines in single-line text fields confuses users,
and that means poor security, among other things.

The default (and perhaps only) behaviour should be editor.single.pasteNewlines = 3.

Comment 156

[(not currently active) Ted Mielczarek]

*** Bug 246912 has been marked as a duplicate of this bug. ***

Comment 157

[(not currently active) Ted Mielczarek]

Attachment: SeaMonkey patch (Checked in trunk)

SeaMonkey patch, dependend on bug 253481

Comment 158

[(not currently active) Ted Mielczarek]

Attachment: Firefox patch (Checked in trunk)

same as above for Firefox

Comment 159

[(not currently active) Ted Mielczarek]

Comment on attachment 152614 [details] [diff] [review]
Patch for discussion: reset urlbar if it changed after loadURI

Hopefully nobody minds if I obsolete this patch.

Comment 160

[Mike Connor [:mconnor]]

Comment on attachment 202045 [details] [diff] [review]
Firefox patch (Checked in trunk)

I think this is probably the sanest behaviour for the URL bar.  Can we get a followup bug/patch for switching to converting to spaces for the search bar?

Comment 161

[(not currently active) Ted Mielczarek]

Comment on attachment 202044 [details] [diff] [review]
SeaMonkey patch (Checked in trunk)

Trolling for rs ...

Comment 162

[[e-mail]]

Comment on attachment 202044 [details] [diff] [review]
SeaMonkey patch (Checked in trunk)

Well it's a start...

Comment 163

[Ian Neal]

Comment on attachment 202044 [details] [diff] [review]
SeaMonkey patch (Checked in trunk)

Checking in
xpfe/browser/resources/content/navigator.xul;
new revision: 1.435; previous revision: 1.434
done

Comment 164

[Ian Neal]

Comment on attachment 202045 [details] [diff] [review]
Firefox patch (Checked in trunk)

Checking in
browser/base/content/browser.xul;
new revision: 1.275; previous revision: 1.274
done

Comment 165

[(not currently active) Ted Mielczarek]

Fixed on trunk!

Comment 166

[Peter van der Woude [:Peter6]]

the Firefox patch caused Bug 321279

Comment 167

[Peter van der Woude [:Peter6]]

the Firefox patch also caused bug 324184
 

Comment 168

[tylernt]

I just downloaded FireFox 2.0 and found editor.singleline.pastenewlines is still set to 1 instead of 3, and pasting a multiline URL into the Adress bar still does not work with a setting of 1. I thought this bug was resolved?

Comment 169

[(not currently active) Ted Mielczarek]

It's fixed on trunk.  This fix will be in Firefox 3.

Comment 170

[Phil Ringnalda (:philor)]

*** Bug 364004 has been marked as a duplicate of this bug. ***

Comment 171

[Ryan Flint [:rflint] (ping via IRC for reviews)]

*** Bug 364948 has been marked as a duplicate of this bug. ***

Comment 175

[Nick Burch]

I think this has recently been broken again. I've recently upgraded to Firefox 29.0, and now when I paste in line-broken URLs to the location bar, the line-breaks show up as spaces, which means they're then no longer the right URL

eg if you copy a URL into the address bar:
http://example.com/line-wrapped-
url/

It now no longer comes through as "http://example.com/line-wrapped-url/", as this bug fixed it to, but is instead "http://example.com/line-wrapped- url/" (which isn't the same URL so doesn't get you to the right place)

Comment 176

[Jesse Ruderman]

Indeed, this is broken again. I filed bug 1014246.