bjhoops1@, in order to triage this issue i need some more information,

In the attached screenshot, i have highlighted area which says '<p class = "p1">'
1. I am able to see this text in Mac OS only not in Windows and Linux.
   Is this issue is specific to Mac OS only ?

2. In Mac OS, safari browser, i am unable to see the highlighted text.
   Should we have to show this text or not ? 

Anyone from dev team look into this issue.

Deleted: Screen Shot 2016-10-18 at 3.01.58 PM.png 461 KB

	Screen Shot 2016-10-18 at 3.01.58 PM.png 461 KB View Download

Thanks, kkaluri, sorry I forgot to mention I have only tested this on OS X.  I am not sure how Windows/Linux Chrome handles it.  

Yeah, if you paste that same RTF "Sample Text" into the contenteditable div in OS X Safari, you won't get that `class="p1"` and you won't get the <style> tag - you'll just get an inline style.  This is how Chrome 53 worked as well.  

The new method with the magic class names and style tag is much harder to work with and unique as far as I know among browser strategies for handling pasted RTF text.  

Let me know if you need any more clarification, thanks!

Thank You  bjhoops1 for your feedback.

On checking this issue in Windows 10  and Ubuntu 14.04, this issue doesn't exist in this platforms.

In the Mac OS, i have installed  the Old installer M30 - 30.1549.0 and in this version also it showing the same "class p1" and <style tag>.

Please look into the screen-cast and let us know that it is the same behavior that you are experiencing in the present stable version 54.0.2840.59..

Thank you...

Deleted: Issue-656842-1.mov 9.1 MB

Issue-656842-1.mov 9.1 MB Download

Thanks, kkaluri.  So if you look in the screencast, the old Chrome 30 *does* have the `class="p1"`, but it does NOT have a separate <style> tag inside the <div>.  

That "style="border: 1px solid black;" that you see is just some style I added to the container `contenteditable` div.  It was there before you pasted the Sample Text in.  

Had this been Chrome 54, you would have seen something like 

<div style="border:1px solid black;" contenteditable="true">
   <style type="text/css">p.pl { /* Some style */}</style>
   <p class="p1">Sample Text</p>
</div>

Hope this helps. 

Thank You  bjhoops1 for your detailed feedback.

Able to reproduce this issue on Mac 10.12 on latest chrome Stable version 54.0.2840.59. 
Issue is broken in M54. Below are the bisect details for the same:

Bisect Info:
===========
Good Build : 54.0.2789.0,  Revision Range (403806)                                           
Bad Build  : 54.0.2790.0, Revision Range  (404030)

After executing the bisect script, i got the following CL's between good and bad build versions
https://chromium.googlesource.com/chromium/src/+log/38e3def544b70d6bc5a6a0a0959c893071dcc0be..c0ac8b47882ec7b0643a6fb87e1746e28c34feb8


The suspecting Change Log is :
-----------
https://chromium.googlesource.com/chromium/src/+/8ebfae3567b1bfe350286345bb0c338b9f354fe1


From the above CL suspecting the below change
Review URL:  https://codereview.chromium.org/2121613003

dominicc@- Could you please look into this issue, if it's related to your change?  if not could you please help us to reassign this issue to the right owner.

Thank You...

8ebfae3567b1bfe350286345bb0c338b9f354fe1 made this change,  Issue 121163  has details. This was intentional. The motivation is to let editors get information about the style of pasted content, which used to be stripped. We experimented with serializing styles and producing inline styles, but in the end decided to include style tags.

Other browsers (eg Firefox and Edge) include a style tag too, although the exact details of what styles are included varies from browser to browser. Firefox 49 elides an @page rule than Chrome includes for example. Note the exact markup that browsers see can depend on what's serializing the RTF, too.

If your editors work in FF/Edge they should work in Chrome.

If you want to produce inline styles you could walk over the element tree, use getComputedStyle and then serialize it to a style attribute, then remove the style tags. It is easy to produce content with quite bloated inline styles this way, which the style tag avoids, although the style tag has other problems like styles applying to existing content. You can limit the bloat somewhat by not serializing styles which match defaults.

dknox probably knows better about the release notes question.

For now I'm going to close this as "WontFix" because we intend it to work this way; your feedback is the first indicating there's a problem. We will continue to monitor feedback.

Re: release notes - I will think about a way that we can more effectively communicate changes like this to developers in the future.