5663 - Copy and paste of entities does not work.

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[sujay]

using 4/28 build of apprunner on all platforms:

when content is found to contain the <
and > markup characters. These codes are written out as character entities. This
means that they no longer get interpreted in the XIF as XML markup.

Comment 1

[Greg Kostello]

This is by design. All '<' and '>" characters that are in the content model are
required to be output as &lt; and &gt; respectively.

Please let me know if you had something else in mind.

Comment 2

[Simon Fraser [no longer active]]

But when the user types "<", shouldn't we be putting "&lt;" into the content?
I'm pretty sure we don't do this now.

Comment 3

[Simon Fraser [no longer active]]

Greg, I'm reopening simply because I don't want this to disappear without getting
a good answer  ;-)

Comment 4

[Greg Kostello]

Working as advertised. Double checked with Simon.

Comment 5

[sujay]

Greg, when did this fix go in? I just tried to verify it on the 5/6 build.
I now see different results. When I cut/copy some text with "<" and ">"
in the string and then paste it, I see the symbols "y" with umlauts.
It doens't look fixed in the 5/6 build.

I'm re-opening this one, kick it back to me if your fix intended
to go in for the 5/7 build...

Comment 6

[Simon Fraser [no longer active]]

Adjusted summary, removed resolution.

Comment 7

[Simon Fraser [no longer active]]

cc: akk.

Comment 8

[Simon Fraser [no longer active]]

cc: akk.

Comment 9

[Akkana Peck]

I'll take this.  We should be able to handle pasting of those characters, and
right now we seem to be ignoring them in a plaintext paste.

Comment 10

[Akkana Peck]

Marking M7, but I'm really hoping to get this fixed for M6.

Comment 11

[Akkana Peck]

One problem I'm seeing: I get into nsHTMLToTXTSinkStream::EncodeToBuffer and get
the assert: "The unicode encoder needs to be initialized".  There's no encoder
because the charset equals ucs2 in InitEncoder, so it thinks it doesn't need an
encoder (but then in EncodeToBuffer it thinks it can't proceed without one).
EncodeToBuffer gets called with argument of "lt" and "gt" and it doesn't return
any encoding for these entities because of mEncoder being 0.

In nsHTMLToTXTSinkStream::AddLeaf(), if I add the following clause in front of
the EncodeToBuffer(text) call, entities start working again:

    if (!mUnicodeEncoder)
    {
      char* str = text.ToNewCString();
      EnsureBufferSize(text.Length()+1);
      strcpy(mBuffer, str);
      delete[] str;
    }
    else


I'll do some more investigating to find out whether this is really the right
place to fix this, and to test to make sure it doesn't break anything else, but
we should be able to get this fixed in the M6 timeframe (changing milestone
accordingly).

Comment 12

[Akkana Peck]

Greg has approved my fix (which I moved into EncodeToBuffer since it seemed to
belong better there) and asked me to hand the bug off to him to find out why
mUnicodeEncoder isn't being initialized.  But meanwhile, the symptom is fixed
and you should be able to copy entities now.

Comment 13

[sujay]

actually I'll wait till this one is marked RESOLVED-FIXED before
verifying...

Comment 14

[Greg Kostello]

Resolved-Fixed. Akkana's checkin fixes the problem.

Comment 15

[sujay]

verified in 5/19 build.

Comment 16

[leger]

Reassigning all bugs Assigned To kostello to buster

Comment 17

[buster]

All these bugs were marked "New" when Jan transfered ownership of them to me.
They were all resolved and need to be marked "Verified" again.

Comment 18

[leger]

This was Verified on 05/19/99...resetting back to Verified...Bugzilla wacked
out.