[jitsi-dev] [jitsi] Different approach to (plain text) chat message processing in ChatConversationPanel. (#53)

This is a follow up to a recent email thread: "Workings of ChatConversation methods processMessage, formatMessage, processLinksAndHTMLChars (escaping contact names)". This pull request contains an implementation of the proposition to handle messages as pure HTML and on first occurrence escape all plain text message contents. This approach does not use PLAINTEXT-tags, which prevents some of the styling issues that occur when previously opened tags, such as H4, are lost after use of plaintext.

This implementation does not yet solve *every* problem I have identified, however it should be on par with the current implementation, minus the issues caused by the plaintext-tags. I have done some testing on several protocols and I have also been able to establish a OTR session. I needed to take a slightly different approach to identifying "plain text" sections. More on that in the commit message below.



This modification fixes issues w.r.t. message caused by loss of styling
due to opening/closing <plaintext> tags. Additionally it simplifies
html / plain text message handling and text replacement.

Implemented a different approach to ChatMessage processing. This new
implementation strictly watches for the moment when a chat message
(possibly HTML already, but might also be plain text) is definitely
converted into HTML. This happens when certain processing steps are

As soon as these processing steps are taken, the approach changes into
HTML by default and every piece of text that still is plain text will be
HTML-escaped. Just before appending the new text message to the (HTML)
chat document, we always have HTML "text" and as soon as a processing
step is used of which we know that it definitely converts to HTML, we
start using the HTML content type. This also means that on a number of
occasions we have removed the contentType parameter, since we already
know or have this information.

Since we now know for sure that from a certain moment on, we are
strictly dealing with HTML "text" and we also know that everything plain
text will be HTML-escaped, we can adopt a different plain text search
pattern (TEXT_TO_REPLACE_PATTERN). This search approach searches for all
text in between lesser than (<) and greater than (>) signs, since we can
be sure that that is normal (escaped) text. We unescape these pieces of
text before running through the replacement services such that they can
behave as they always have. This shouldn't break (much of) the
Replacement Services implementations.

Also check and tag hyperlinks for HTML messages.

Added dependency to Apache Commons Lang to swing-ui.

Removed option skipSmiley. It is not needed anymore, now that hyperlink
hrefs aren't found anymore.
You can merge this Pull Request by running:

  git pull https://github.com/cobratbq/jitsi fix-message-formatting

Or you can view, comment on it, or merge it online at:


-- Commit Summary --

  * Different approach to (plain text) chat message processing.

-- File Changes --

    M build.xml (2)
    M src/net/java/sip/communicator/impl/gui/main/chat/ChatConversationPanel.java (421)
    M src/net/java/sip/communicator/impl/gui/main/chat/ChatHtmlUtils.java (75)
    M src/net/java/sip/communicator/impl/gui/main/chat/ChatPanel.java (8)
    M src/net/java/sip/communicator/impl/gui/main/chat/ChatWritePanel.java (13)
    M src/net/java/sip/communicator/impl/gui/main/chat/history/HistoryWindow.java (10)
    M src/net/java/sip/communicator/impl/gui/swing.ui.manifest.mf (3)

-- Patch Links --


Reply to this email directly or view it on GitHub:

Please wait with merging this thread. I noticed that there are a bunch of out-of-date comments that still describe or hint at the old situation. I'll update them where necessary.


Reply to this email directly or view it on GitHub:

Okay, so it seems I got almost everything.


Reply to this email directly or view it on GitHub:

More improvements are coming up ... I will commit these myself, so closing this pull request.


Reply to this email directly or view it on GitHub:

Closed #53.


Reply to this email directly or view it on GitHub: