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.

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.

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.

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.

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.

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?

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.

Moving to M16 to facilitate M15 checkpoint stability branch.

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

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?

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+

adding the brackets in the status

setting priority in status whiteboard

*** 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.)

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.

akk: fixed?

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.

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

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.

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

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.

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

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

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.

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

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.

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>

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.

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

*** 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

apps maybe?

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.

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

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

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

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

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.

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.

*** 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.)

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.

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.

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

*** 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)

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

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.

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

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

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

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

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.

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 on attachment 202044 [details] [diff] [review] SeaMonkey patch (Checked in trunk) Trolling for rs ...

Comment on attachment 202044 [details] [diff] [review] SeaMonkey patch (Checked in trunk) Well it's a start...

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

Fixed on trunk!

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

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.