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.

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.

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

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

Working as advertised. Double checked with Simon.

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

Adjusted summary, removed resolution.

cc: akk.

cc: akk.

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.

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

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

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.

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

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

verified in 5/19 build.

Reassigning all bugs Assigned To kostello to 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.

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