IE9 copy & paste removes line returns

WTF!! i dont get it. why does IE9 keep removing all the new lines returns from web pages when i copy and paste.

How can i change it to work like all other windows app???

I have seen the same thing, although it doesn't always happen.

Annoyingly, one of the places where it happens is with code samples on StackOverflow, which is very annoying.

I'm still waiting for a web browser which lets me select individual words, letters, or sentences without selecting half of the entire page for no reason. Count yourself lucky. Sorry I wasn't helpful.

Ditto. It's also bad copying from a document on SkyDrive via IE9. Highlight the stuff you want, it copies the text, and a space, and a line break.

IE9 is a great browser and all, but this is what makes it hard to use. There won't be an update to this for at least a few weeks, probably months.

Firefox's accelerated release schedule is not such a bad idea. Neither is Chrome's. Little annoyances like this just won't get fixed . When it dose, it will be KB840852 with a change log stating "fixes some usability issues with IE9".

@wsdotnet: I have firefox installed just for this. I find copy and paste in IE9 beyond my comprehension

Man... i just cant win. i switched from FFox 4/5 to IE9, i guess Chrome it is then. Good job IE team, way to go. Please excuse my rant. 

Could swear I reported this bug long ago, maybe twice.. I see IE*8* and this happens a lot.

Try this: copy the text, do Run->WRITE (wordpad) and paste there? Are the lines preserved?

I find that very often when copying code (say from stackoverflow) I have to go through wordpad to preserve the line endings.

I don't think Connect's "My feedback" is showing all IE bugs I've reported just some latest ones. I'd have linked the bug otherwise.

> without selecting half of the entire page for no reason.

This happens so much that I now do the selection backwards from end to begin, doesn't always work but helps sometimes.

Is this copy/paste problem when copying web page content that spans more than one html element?

I've seen many a web site where the visual display of the content is 100% readable but when you look at how it is coded the content is actually split across multiple elements that may or may not be in close proximity (code wise).  Can't fault any browser for that scenario.

What is an example web page that exhibits this behavior?

I picked a random entry on stackoverflow

http://stackoverflow.com/questions/6956267/datagridview-optimize-performance-using-paging

, copied the contents (CTRL + C) and pasted it below.  Seems to have worked just fine.

In my app Datagridview displays object Proxy

• Proxy has two properties Address, Status

• DataGridview is bound to List which holds the Proxy objects.

• The DataGridView and UI becomes unresponsive due to the heavy load on the memory, as the list reaches 1 million proxy count.

• The app is harvesting proxies from diffrent websites, how do I scale the application to handle huge lists.

My concern, is harvesting, and implementing paging at the same time.

Paging with SQLCe, is it a good solution?? or will sql ce slow the harvesting process, or is there a better solution, i don't know.

the app harvests arround 500 - 1700 proxies per second, it is a feature, to extract "as fast as possible", I now there are other obvious limitations, bottle necks, but i am ignoring them for now.

Please advice how do i keep the speed, and make it scale, best practices., I am not sure about SQLCe

@davewill: Now pick an entry on StackOverflow that has code in it. Copy the code and paste it in Visual Studio.

@Sven Groot: I picked a couple at random

http://stackoverflow.com/questions/6293884/custom-serialization-of-an-object-in-net

http://stackoverflow.com/questions/6958958/how-to-handle-tcplistener-an-existing-connection-was-forcibly-closed-by-the-remo

They pasted just fine into VS 2010.  The OP seemed to convey this happens every time.  Maybe not.  Have you a specific entry that doesn't work for you?  I'll try that.

@davewill: I tried the code from those samples, and it has no line breaks when I copy from IE9, and paste in VS2010.

EDIT: Tried no add-ons mode, same result.

@Sven Groot: Ditto (IE9/VS2010). Worked fine w/ FF v5.0.1/VS2010.

However, I nearly always keep a text editor open to pate into/copy from just so I can strip unwanted formatting. I know some apps provide the past as text option but so many do not that it's just become an (annoying) habit... do a lot of writing/documentation.

Is this a problem with IE, per se, or a problem with the Visual Studio editor? It seems that any program that supports rich text (WordPad, Word, Excel, Publisher, Outlook, and even PowerPoint) preserves the CRLFs from IE.

We all know that VS editor supports syntax coloring (and pasting FROM VS to all those programs listed above does preserve the colors), but the editor itself doesn't truly support rich text since you can't change the typeface, size, color, etc. of individual blocks of text within the editor.

What I've found is that VS (and NotePad as well) preserve line breaks AS RENDERED from <br />, <p></p>, <div></div> and <table></table> elements, but they do not preserve ASCII-encoded line breaks within a <pre></pre> element.

@Sven Groot: Ok.  We have a common set of inputs and differing output.  Let narrow down.  When pasting in VS2010 does all the code end up on one big line?  Does this exact same thing happen when pasting into Notepad?  What about Word?

I suspect the answers will be:

VS2010 - all one big fat line

Notepad - looks as copied

Word - ??

Post the confirmation results.

Here is a screenshot of my vs2010 paste

https://skydrive.live.com/?cid=f635ae20b5c8d6d0&sc=documents&uc=1&id=F635AE20B5C8D6D0%21140#cid=F635AE20B5C8D6D0&id=F635AE20B5C8D6D0%21183&sc=documents

@davewill: after some testing, it seems that all this is caused by the fact that IE treats <br> within a <pre> inconsistently: they get honored for rendering, but ignored when the text content is extracted. This doesn't happen for <br>'s outside a <pre>, nor when the RTF and HTML contents of the clipboard are generated. This explains why this happens for Notepad (that looks at the text content of the clipboard) but not for Wordpad (which prefers RTF).

So, it would seem to be IE's faut... but even the prettifier used by StackOverflow deserves some kicking: it seems it replaces line breaks with <br> and every second blank with &nbsp;. Which makes the <pre> useless and introduces the problem in IE (IE is perfectly happy with line breaks in a <pre>, or <br> outside a <pre> and would work fine with the <pre> block you can see in the page source). A job well done, no doubt.

As to Visual Studio, it's innocent of all this mess. It finds the text content in the clipboard and uses that, period. And it's a good thing it does just that... imagine what would happen if it detected the presence of HTML code in the clipboard and tried to be smart about it: it would probably just fire up MSHTML, convert the HTML to text and paste that. Which would have the only effect of making the other browsers work the same as IE. Oops...

You mean like when you copy an address with two lines and it paste as a single line in the search bar? No more copy twice for searching address?

@davewill:

It shows up as one line in VS2010, Notepad, and Notepad++. It shows up as copied in Word (including colours and stuff).

I took a peek at the clipboard contents, and there are three five formats used, three of which are plain text, one is HTML, and one is RTF. The plain text formats (which is what VS and Notepad will use) do not contain new lines. The HTML version contains the entire HTML (it seems this is what Word uses), and the RTF version preserves line breaks but not colours.

So it seems the issue is that IE9 strips all HTML, including <br/> elements, when setting the plain text data on the clipboard when copying from a <pre>.

Of course, that doesn't answer the question of why it doesn't do that for you, but that's what happens on my system anyway. So VS has nothing to do with it, it's IE's fault. Expecting VS to parse the HTML or RTF data formats is not reasonable.