Closed Bug 23485 Opened 25 years ago Closed 19 years ago

browser window should strip newlines from url pastes

Categories

(SeaMonkey :: UI Design, defect, P2)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bugzilla, Assigned: ted)

References

(
URL
)

Details

(Keywords: helpwanted, polish)

Attachments

(2 files, 1 obsolete file)

SeaMonkey patch (Checked in trunk)
1.63 KB, patch
neil
: review+
neil
: superreview+
Details | Diff | Splinter Review
Firefox patch (Checked in trunk)
1.46 KB, patch
mconnor
: review+
Details | Diff | Splinter Review 
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.
Assignee: shuang → akkana
Component: UE/UI → Editor
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.
Assignee: akkana → don
Component: Editor → Browser-General
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.
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.
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.
Is this a dup of bug 22388?
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.
Whiteboard: a
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.
Do what 4.x does, which is #1, above.
Whiteboard: a
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.
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.
But this "feature" helps alot when a URL is just broken into two or more parts
most probably by a linebreak mechanism.
Assignee: don → german
Target Milestone: M14
cc'ing akkana, who was one of the people involved in the original thread.
assigning bug to german, we need a UI decision here.
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.
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.)
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.
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?
Status: NEW → ASSIGNED
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.
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.
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.
Ben Bucksch is the one that took over the URL detection code.

- rhp
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.
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.
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.)
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
I do not think this is a beta or even m14 candidate so barring any objections I 

will move that to m15.
Target Milestone: M14 → M15
Moving to M16 to facilitate M15 checkpoint stability branch.
Target Milestone: M15 → M16
M16 has been out for a while now, these bugs target milestones need to be 
updated.
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
Target Milestone: M16 → M18
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.
We should go with the removal of CRLF from the uri, do not convert to space.
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?
Assignee: german → akkana
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Keywords: nsbeta3, polish
The netlib part (removing CRLF) can happen in 

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

where we already do a trim of spaces.

yea, I'm w/ akkana on this one. and andreas provides the point to do the 
conversion.
OK! Akkana take it from here...

setting to nsbeta3+
Whiteboard: nsbeta3+
adding the brackets in the status
Whiteboard: nsbeta3+ → [nsbeta3+]
setting priority in status whiteboard
Priority: P3 → P4
Whiteboard: [nsbeta3+] → [nsbeta3+][p:4]
*** Bug 45953 has been marked as a duplicate of this bug. ***
Bumping up to P2 since the netlib part of this bug will also have to happen. 
(It should be easy, though.)
Priority: P4 → P2
Whiteboard: [nsbeta3+][p:4] → [nsbeta3+][p:2]
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.
Akk, why not just ap it to space? For URLs in freetext, there's no difference
between any kind of whitespace.
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.
Users write paths to local directories in the urlbar too, and on Windows they do 
contain \ so it's no good special char.
Whiteboard: [nsbeta3+][p:2] → [nsbeta3+][p:2] FIX IN HAND
akk: fixed?
QA Contact: elig → BlakeR1234
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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
So, you're loading another URL (possibly even another server) than you see
before you trigger the load? That is bad. Sorry, REOPENing.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
When *pasting* in the urlbar (not generic texfields), I would either strip
newlines or replace them with spaces.
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".
Oh, didn't relize that it was so hard to intercept a "paste".
vrfy fixed
Status: RESOLVED → VERIFIED
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?
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.

This is not fixed. Having multiple partly hidden lines in the Location field is 
no OK.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Re-closing.  I fixed it according to the most recent agreement in the bug, and
the functionality works.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
"agreement" ?
As a normal user I simple understand *nothing* of whats going on when pasting a 
"multiline" url into the Location field.
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Priority: P2 → P4
Whiteboard: [nsbeta3+][p:2] FIX IN HAND
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 buster@netscape.com 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.
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."
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 ...
Keywords: helpwanted
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.
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.
Yup, Mac truncates the line at the first linebreak, and I think it's reasonable 
for us to do this also.

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.
Status: REOPENED → ASSIGNED
Summary: Cut and paste URL over multiple lines makes weird URL → browser window should strip newlines from url pastes
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>
Whiteboard: [nsbeta3+]
Whiteboard: [nsbeta3+] → [nsbeta3+] this is a test
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.
Whiteboard: [nsbeta3+] this is a test → [nsbeta3+]
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.
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.
Akkana -- what is the current state of this bug? What needs to be done here?
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.
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
Severity: normal → enhancement
Whiteboard: [nsbeta3+] → [nsbeta3-]
Target Milestone: M18 → Future
*** Bug 57031 has been marked as a duplicate of this bug. ***
*** Bug 39258 has been marked as a duplicate of this bug. ***
*** Bug 67319 has been marked as a duplicate of this bug. ***
talked with akkana on this one, reassigning to browser team
Assignee: akkana → asa
Status: ASSIGNED → NEW
QA Contact: blakeross → doronr
apps maybe?
Assignee: asa → vishy
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
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.
Assignee: vishy → akkana
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 ...
Assignee: akkana → mcafee
->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.]
Keywords: nsbeta3 → mozilla0.9
Whiteboard: [nsbeta3-]
Target Milestone: Future → ---
see bug 72659 for a similar request for the open location dialog
*** Bug 72659 has been marked as a duplicate of this bug. ***
*** Bug 77932 has been marked as a duplicate of this bug. ***
nav pretriage: recommend nsbeta1-, Future. 
nav triage team:

Marking as per Vishy's pretriage comments. nsbeta1- and future
Keywords: nsbeta1-
Target Milestone: --- → Future
*** Bug 81963 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0
OS: Windows 98 → All
Hardware: PC → All
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.

sorry I didn't get to this.  Over to vishy to find an owner.
Assignee: mcafee → vishy
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...
We strip newlines from urls in necko. If that is not happening please give some
examples.
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.


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.
*** Bug 114530 has been marked as a duplicate of this bug. ***
->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.
Assignee: vishy → hewitt
Severity: enhancement → normal
Priority: P4 → P2
Target Milestone: Future → mozilla1.0
*** Bug 121291 has been marked as a duplicate of this bug. ***
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.)
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla1.1
removing myself from the cc list
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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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.
*** Bug 134939 has been marked as a duplicate of this bug. ***
*** Bug 136724 has been marked as a duplicate of this bug. ***
*** Bug 137391 has been marked as a duplicate of this bug. ***
*** Bug 164428 has been marked as a duplicate of this bug. ***
Fixed in Chimera (bug 160132).
QA Contact: sairuh → pmac
*** Bug 177503 has been marked as a duplicate of this bug. ***
*** Bug 183984 has been marked as a duplicate of this bug. ***
Should the summary be changed to include also INPUT form controls? (see bug 187785)
#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)
Depends on: 77932
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!

*** Bug 136741 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.1alpha → ---
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!

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.
This bug seems to be fixed in Firebird 20030903 on Linux.  Anybody still seeing
it on other platforms?


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.
*** Bug 221129 has been marked as a duplicate of this bug. ***
*** Bug 229254 has been marked as a duplicate of this bug. ***
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.
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 ?
*** Bug 237004 has been marked as a duplicate of this bug. ***
*** Bug 238843 has been marked as a duplicate of this bug. ***
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
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?
*** Bug 162710 has been marked as a duplicate of this bug. ***
This bug is truly annoying, as I paste wrapped URLs on a regular basis. The
current assignee is gone, so I'll reset it.
Assignee: hewitt → jag
Status: REOPENED → NEW
QA Contact: pmac → pawyskoczka
QA Contact: pawyskoczka → benc
*** Bug 246912 has been marked as a duplicate of this bug. ***
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...
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'.
Pasting

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

Brings me to http://goodsite.com.badsite.com/ while displaying
http://goodsite.com ...
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?
> 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?
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 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.
*** Bug 250603 has been marked as a duplicate of this bug. ***
Depends on: 253481
(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?
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.
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?
*** Bug 264726 has been marked as a duplicate of this bug. ***
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!"
*** Bug 269200 has been marked as a duplicate of this bug. ***
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.
Product: Core → Mozilla Application Suite
"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?
"http://dcu.com
:test@badsite.com"

where badsite is configured to require auth (over http).
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.
> 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
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).
(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:password@www.microsoft.com/

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.
Attachment #152614 - Flags: review?(neil.parkwaycc.co.uk)
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?
Um, in my last post, "doesn't convert newlines to pastes" should have read
"doesn't convert newlines to whitespaces". Sorry.
*** Bug 294527 has been marked as a duplicate of this bug. ***
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?
*** Bug 299827 has been marked as a duplicate of this bug. ***
*** Bug 302491 has been marked as a duplicate of this bug. ***
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.
*** Bug 246912 has been marked as a duplicate of this bug. ***
SeaMonkey patch, dependend on bug 253481
Assignee: jag → ted.mielczarek
Status: NEW → ASSIGNED
same as above for Firefox
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.
Attachment #152614 - Attachment is obsolete: true
Attachment #152614 - Flags: review?(neil.parkwaycc.co.uk)
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?
Attachment #202045 - Flags: review+
Comment on attachment 202044 [details] [diff] [review]
SeaMonkey patch (Checked in trunk)

Trolling for rs ...
Attachment #202044 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #202044 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 202044 [details] [diff] [review]
SeaMonkey patch (Checked in trunk)

Well it's a start...
Attachment #202044 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #202044 - Flags: superreview+
Attachment #202044 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #202044 - Flags: review+
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
Attachment #202044 - Attachment description: SeaMonkey patch → SeaMonkey patch (Checked in trunk)
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
Attachment #202045 - Attachment description: Firefox patch → Firefox patch (Checked in trunk)
Fixed on trunk!
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 19 years ago
Resolution: --- → FIXED
the Firefox patch caused Bug 321279
the Firefox patch also caused bug 324184
 


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?
It's fixed on trunk.  This fix will be in Firefox 3.

*** Bug 364004 has been marked as a duplicate of this bug. ***
*** Bug 364948 has been marked as a duplicate of this bug. ***
Blocks: 368263
Depends on: 395204
Blocks: 490713
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)
Indeed, this is broken again. I filed bug 1014246.
See Also: → 1847516
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: