insertHtml left trim text

[Garry Yao]

Reproducing Procedures

1. Open the 'api' sample page, load the editor with the following content and selection.

   some^text
   

2. Load the insertion area with the following content:

    insertion 
   

3. Click on 'Insert HTML' button.
4. Switch to 'Source' mode.

• Actual Result:

  <p>
  	someinsertion text</p>
  

• Expected Result:

  <p>
  	some insertion text</p>
  

Note that the left side whitespace has been trimmed, which is wrong.

[Garry Yao]

Ticket Test added at :
​http://ckeditor.t/tt/4746/1.html.

[Garry Yao]

We could have an option on the dataprocessor to control the parser behavior properly.

[Garry Yao]

Another TC: Inserting inside a <pre> collapses all line-breaks and tabs.

[Garry Yao]

Introduce an idea that allows context sensitive html parsing with ease.

[Sa'ar Zac Elias]

The element should not be noticable in the elements path.

[Garry Yao]

Align patch with trunk. @Saar, this's a virtual context that only seen in the parser, it will not exist in wysiwyg at all.

[Sa'ar Zac Elias]

Replying to garry.yao:

@Saar, this's a virtual context that only seen in the parser, it will not exist in wysiwyg at all.

I can move the cursor into the span, so it's visible in the elements path. The user should not know we have a temporary span there.
4746_2 is not working for me on IE for some reason, 4746 does though.
Also please note that after the patch the data variable is set twice.

[Garry Yao]

Well, it seems I'm quite naive for IE as even we fixed our parser, IE's 'pasteHTML' still won't let this leading space pass, so the fix only partially work, in this case we will need to again wait for #5309, defer it to 3.5

[Garry Yao]

Now that we've reworked the ​editor::insertText method which should be relied on for inserting plain text (where leading whitespaces are preserved).

[James]

The initial test case is still reproducible on the nightly build and should be reopened.

[Wiktor Walc]

@james - I've created a separate issue: #6876 to check it.