[jitsi-dev] (Upcoming) Modifications to message formatting for displaying the chat conversation


#1

Hi all,

I am planning to merge a modified implementation of the message
formatting code that processes message that are about to be displayed in
the chat conversation window. This code improves on the following aspects:

1. A different approach to handling (mixed) plain text and html
messages. I process the plain text message once, strictly leveraging the
fact that the code knows exactly when text is plain text and when it
gets turned into HTML (i.e. at least partially formatted for displaying
already).

2. Not using <plaintext> tags anymore, since these cancel any active
formatting, such as light-grey from system messages, headings and such.

3. Strict HTML escaping for any text that should be displayed as is,
this includes names of chat rooms, members and subjects. This is
important since IRC channel names allow for almost any character, so you
can create a small HTML document as a chat room name, and we'd like to
prevent HTML injection.

4. Now that <plaintext> tags are gone, I've taken a different approach
to processing messages based on the plain text parts of the message:
this approach searches for text in between the HTML tags for processing
and escapes it automatically such that you can process based on the
original content, instead of the HTML-escaped content.

5. Separate implementations, based on a public interface for the
preprocessing steps that are executed on all incoming messages. There is
an interface called 'Replacer' for which a number of implementations
exist that were previously available as individual methods. (A separate
package is created for these implementations.)

6. Fixed processing URL's in HTML text. (This previously only worked for
discovering hyperlinks in plain text message.)

7. Fixed ordering of processing keywords vs. hyperlinks: previously if a
keyword was highlighted, it would break the URL and the URL wouldn't be
recognized as such any more.

8. And finally, I've improved to regexp that searches for plain text
content to recognize both tags (by <> brackets) and attribute values by
quotes (") such that we can quite reliably distinguish parts from HTML
tags from actual text content.

I plan to push these changes by tomorrow evening if there are no
objections. I'd like to give you all a chance to respond beforehand,
because this touches some quite significant code. If I need to wait to
do some more testing, I'm also fine with that.

You can find the code at
https://github.com/cobratbq/jitsi/commits/fix-message-formatting
Any feedback is welcome!

Kind regards,
Danny


#2

Hi Danny,

Hi all,

I am planning to merge a modified implementation of the message
formatting code that processes message that are about to be displayed in
the chat conversation window. This code improves on the following aspects:

1. A different approach to handling (mixed) plain text and html
messages. I process the plain text message once, strictly leveraging the
fact that the code knows exactly when text is plain text and when it
gets turned into HTML (i.e. at least partially formatted for displaying
already).

2. Not using <plaintext> tags anymore, since these cancel any active
formatting, such as light-grey from system messages, headings and such.

3. Strict HTML escaping for any text that should be displayed as is,
this includes names of chat rooms, members and subjects. This is
important since IRC channel names allow for almost any character, so you
can create a small HTML document as a chat room name, and we'd like to
prevent HTML injection.

4. Now that <plaintext> tags are gone, I've taken a different approach
to processing messages based on the plain text parts of the message:
this approach searches for text in between the HTML tags for processing
and escapes it automatically such that you can process based on the
original content, instead of the HTML-escaped content.

5. Separate implementations, based on a public interface for the
preprocessing steps that are executed on all incoming messages. There is
an interface called 'Replacer' for which a number of implementations
exist that were previously available as individual methods. (A separate
package is created for these implementations.)

6. Fixed processing URL's in HTML text. (This previously only worked for
discovering hyperlinks in plain text message.)

7. Fixed ordering of processing keywords vs. hyperlinks: previously if a
keyword was highlighted, it would break the URL and the URL wouldn't be
recognized as such any more.

8. And finally, I've improved to regexp that searches for plain text
content to recognize both tags (by <> brackets) and attribute values by
quotes (") such that we can quite reliably distinguish parts from HTML
tags from actual text content.

I plan to push these changes by tomorrow evening if there are no
objections. I'd like to give you all a chance to respond beforehand,
because this touches some quite significant code. If I need to wait to
do some more testing, I'm also fine with that.

All these changes sound really great!! However as you said they touch a significant part of the code and may need an extended testing before pushing. Quite a lot of people use the unstable branch of jitsi, so I suggest that we create a branch and make sure all developers and other interested contributors use this branch for a week or so, before pushing to unstable.

You can find the code at
https://github.com/cobratbq/jitsi/commits/fix-message-formatting

Will have a look. Thanks!

Any feedback is welcome!

I'll move to your branch for my everyday use of Jitsi as soon as you create it.

Cheers,
Yana

···

On 28 Aug 2014, at 22:28, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Kind regards,
Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

Hi all,

So, has anyone had any problems while testing the new formatting code?

I'd like to merge this shortly if possible, since otherwise it'll keep
dragging on. I haven't heard of anyone having issues, so far, and I
haven't noticed anything myself.

Kind regards,
Danny

···

On 08/28/2014 10:28 PM, Danny van Heumen wrote:

Hi all,

I am planning to merge a modified implementation of the message
formatting code that processes message that are about to be displayed in
the chat conversation window. This code improves on the following aspects:

1. A different approach to handling (mixed) plain text and html
messages. I process the plain text message once, strictly leveraging the
fact that the code knows exactly when text is plain text and when it
gets turned into HTML (i.e. at least partially formatted for displaying
already).

2. Not using <plaintext> tags anymore, since these cancel any active
formatting, such as light-grey from system messages, headings and such.

3. Strict HTML escaping for any text that should be displayed as is,
this includes names of chat rooms, members and subjects. This is
important since IRC channel names allow for almost any character, so you
can create a small HTML document as a chat room name, and we'd like to
prevent HTML injection.

4. Now that <plaintext> tags are gone, I've taken a different approach
to processing messages based on the plain text parts of the message:
this approach searches for text in between the HTML tags for processing
and escapes it automatically such that you can process based on the
original content, instead of the HTML-escaped content.

5. Separate implementations, based on a public interface for the
preprocessing steps that are executed on all incoming messages. There is
an interface called 'Replacer' for which a number of implementations
exist that were previously available as individual methods. (A separate
package is created for these implementations.)

6. Fixed processing URL's in HTML text. (This previously only worked for
discovering hyperlinks in plain text message.)

7. Fixed ordering of processing keywords vs. hyperlinks: previously if a
keyword was highlighted, it would break the URL and the URL wouldn't be
recognized as such any more.

8. And finally, I've improved to regexp that searches for plain text
content to recognize both tags (by <> brackets) and attribute values by
quotes (") such that we can quite reliably distinguish parts from HTML
tags from actual text content.

I plan to push these changes by tomorrow evening if there are no
objections. I'd like to give you all a chance to respond beforehand,
because this touches some quite significant code. If I need to wait to
do some more testing, I'm also fine with that.

You can find the code at
https://github.com/cobratbq/jitsi/commits/fix-message-formatting
Any feedback is welcome!

Kind regards,
Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

Hi Yana (and others),

Thanks for your response. I figured it was better to stage it somewhere
else first.
I've pushed the modifications to the branch called
'fix-message-formatting'. It is up to date with master.

I am aware of 2 outstanding issues that are not directly related to my
modifications, so if you encounter those please double-check because
they were probably already there:

1. Vimeo thumbnails (preview) does not work. (Obsolete API IIRC)
2. Preview (after confirmation) of GIF images does not work. (Foss
confirmed this on his running instance of Jitsi.)

Thanks in advance!
Danny

···

On 08/29/2014 12:16 PM, Yana Stamcheva wrote:

Hi Danny,

On 28 Aug 2014, at 22:28, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Hi all,

I am planning to merge a modified implementation of the message
formatting code that processes message that are about to be displayed in
the chat conversation window. This code improves on the following aspects:

1. A different approach to handling (mixed) plain text and html
messages. I process the plain text message once, strictly leveraging the
fact that the code knows exactly when text is plain text and when it
gets turned into HTML (i.e. at least partially formatted for displaying
already).

2. Not using <plaintext> tags anymore, since these cancel any active
formatting, such as light-grey from system messages, headings and such.

3. Strict HTML escaping for any text that should be displayed as is,
this includes names of chat rooms, members and subjects. This is
important since IRC channel names allow for almost any character, so you
can create a small HTML document as a chat room name, and we'd like to
prevent HTML injection.

4. Now that <plaintext> tags are gone, I've taken a different approach
to processing messages based on the plain text parts of the message:
this approach searches for text in between the HTML tags for processing
and escapes it automatically such that you can process based on the
original content, instead of the HTML-escaped content.

5. Separate implementations, based on a public interface for the
preprocessing steps that are executed on all incoming messages. There is
an interface called 'Replacer' for which a number of implementations
exist that were previously available as individual methods. (A separate
package is created for these implementations.)

6. Fixed processing URL's in HTML text. (This previously only worked for
discovering hyperlinks in plain text message.)

7. Fixed ordering of processing keywords vs. hyperlinks: previously if a
keyword was highlighted, it would break the URL and the URL wouldn't be
recognized as such any more.

8. And finally, I've improved to regexp that searches for plain text
content to recognize both tags (by <> brackets) and attribute values by
quotes (") such that we can quite reliably distinguish parts from HTML
tags from actual text content.

I plan to push these changes by tomorrow evening if there are no
objections. I'd like to give you all a chance to respond beforehand,
because this touches some quite significant code. If I need to wait to
do some more testing, I'm also fine with that.

All these changes sound really great!! However as you said they touch a significant part of the code and may need an extended testing before pushing. Quite a lot of people use the unstable branch of jitsi, so I suggest that we create a branch and make sure all developers and other interested contributors use this branch for a week or so, before pushing to unstable.

You can find the code at
https://github.com/cobratbq/jitsi/commits/fix-message-formatting

Will have a look. Thanks!

Any feedback is welcome!

I'll move to your branch for my everyday use of Jitsi as soon as you create it.

Cheers,
Yana

Kind regards,
Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

Hi Yana (and others),

Did you think to switch to the 'fix-message-formatting' branch I've
pushed to github.com/jitsi/jitsi?
I haven't heard anything, so just in case ...

And anyone else who is interested in testing this, please do! The branch
contains modifications to the formatting (hence visualization) of chat
message in the conversation panel, so if weird stuff happens, such as
chat message that are badly formatted or contain weird characters, let
me know.

Kind regards,
Danny

···

On 08/29/2014 12:16 PM, Yana Stamcheva wrote:

Hi Danny,

On 28 Aug 2014, at 22:28, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Hi all,

I am planning to merge a modified implementation of the message
formatting code that processes message that are about to be displayed in
the chat conversation window. This code improves on the following aspects:

1. A different approach to handling (mixed) plain text and html
messages. I process the plain text message once, strictly leveraging the
fact that the code knows exactly when text is plain text and when it
gets turned into HTML (i.e. at least partially formatted for displaying
already).

2. Not using <plaintext> tags anymore, since these cancel any active
formatting, such as light-grey from system messages, headings and such.

3. Strict HTML escaping for any text that should be displayed as is,
this includes names of chat rooms, members and subjects. This is
important since IRC channel names allow for almost any character, so you
can create a small HTML document as a chat room name, and we'd like to
prevent HTML injection.

4. Now that <plaintext> tags are gone, I've taken a different approach
to processing messages based on the plain text parts of the message:
this approach searches for text in between the HTML tags for processing
and escapes it automatically such that you can process based on the
original content, instead of the HTML-escaped content.

5. Separate implementations, based on a public interface for the
preprocessing steps that are executed on all incoming messages. There is
an interface called 'Replacer' for which a number of implementations
exist that were previously available as individual methods. (A separate
package is created for these implementations.)

6. Fixed processing URL's in HTML text. (This previously only worked for
discovering hyperlinks in plain text message.)

7. Fixed ordering of processing keywords vs. hyperlinks: previously if a
keyword was highlighted, it would break the URL and the URL wouldn't be
recognized as such any more.

8. And finally, I've improved to regexp that searches for plain text
content to recognize both tags (by <> brackets) and attribute values by
quotes (") such that we can quite reliably distinguish parts from HTML
tags from actual text content.

I plan to push these changes by tomorrow evening if there are no
objections. I'd like to give you all a chance to respond beforehand,
because this touches some quite significant code. If I need to wait to
do some more testing, I'm also fine with that.

All these changes sound really great!! However as you said they touch a significant part of the code and may need an extended testing before pushing. Quite a lot of people use the unstable branch of jitsi, so I suggest that we create a branch and make sure all developers and other interested contributors use this branch for a week or so, before pushing to unstable.

You can find the code at
https://github.com/cobratbq/jitsi/commits/fix-message-formatting

Will have a look. Thanks!

Any feedback is welcome!

I'll move to your branch for my everyday use of Jitsi as soon as you create it.

Cheers,
Yana

Kind regards,
Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#6

Hey Danny,

I know a few people were on vacation (or in hospital) last week so this
hasn't really been tested that much. It's a rather substantial change so
let's not rush it ... especially if you don't have the time to worry about
it.

On a side note I have noticed that unregistering an IRC account from the
accounts panel and then registering it again seems to leave you with two
instances. Have you seen this?

Also, right clicking on a channel and selecting "join" seems to often fail
for me whe double clicking the channel usually works. Does this sound
familiar?

--sent from my mobile

···

On 14 Sep 2014 9:45 PM, "Danny van Heumen" <danny@dannyvanheumen.nl> wrote:

Hi all,

So, has anyone had any problems while testing the new formatting code?

I'd like to merge this shortly if possible, since otherwise it'll keep
dragging on. I haven't heard of anyone having issues, so far, and I
haven't noticed anything myself.

Kind regards,
Danny

On 08/28/2014 10:28 PM, Danny van Heumen wrote:
> Hi all,
>
> I am planning to merge a modified implementation of the message
> formatting code that processes message that are about to be displayed in
> the chat conversation window. This code improves on the following
aspects:
>
> 1. A different approach to handling (mixed) plain text and html
> messages. I process the plain text message once, strictly leveraging the
> fact that the code knows exactly when text is plain text and when it
> gets turned into HTML (i.e. at least partially formatted for displaying
> already).
>
> 2. Not using <plaintext> tags anymore, since these cancel any active
> formatting, such as light-grey from system messages, headings and such.
>
> 3. Strict HTML escaping for any text that should be displayed as is,
> this includes names of chat rooms, members and subjects. This is
> important since IRC channel names allow for almost any character, so you
> can create a small HTML document as a chat room name, and we'd like to
> prevent HTML injection.
>
> 4. Now that <plaintext> tags are gone, I've taken a different approach
> to processing messages based on the plain text parts of the message:
> this approach searches for text in between the HTML tags for processing
> and escapes it automatically such that you can process based on the
> original content, instead of the HTML-escaped content.
>
> 5. Separate implementations, based on a public interface for the
> preprocessing steps that are executed on all incoming messages. There is
> an interface called 'Replacer' for which a number of implementations
> exist that were previously available as individual methods. (A separate
> package is created for these implementations.)
>
> 6. Fixed processing URL's in HTML text. (This previously only worked for
> discovering hyperlinks in plain text message.)
>
> 7. Fixed ordering of processing keywords vs. hyperlinks: previously if a
> keyword was highlighted, it would break the URL and the URL wouldn't be
> recognized as such any more.
>
> 8. And finally, I've improved to regexp that searches for plain text
> content to recognize both tags (by <> brackets) and attribute values by
> quotes (") such that we can quite reliably distinguish parts from HTML
> tags from actual text content.
>
> I plan to push these changes by tomorrow evening if there are no
> objections. I'd like to give you all a chance to respond beforehand,
> because this touches some quite significant code. If I need to wait to
> do some more testing, I'm also fine with that.
>
> You can find the code at
> https://github.com/cobratbq/jitsi/commits/fix-message-formatting
> Any feedback is welcome!
>
> Kind regards,
> Danny
>
>
>
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>
>

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

Hi Danny,

sorry, I couldn't have a chance to test it earlier (traveling), I will
be testing it the following days and will let you know if I see
something.

Regards
damencho

···

On Wed, Sep 3, 2014 at 1:04 AM, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Hi Yana (and others),

Did you think to switch to the 'fix-message-formatting' branch I've
pushed to github.com/jitsi/jitsi?
I haven't heard anything, so just in case ...

And anyone else who is interested in testing this, please do! The branch
contains modifications to the formatting (hence visualization) of chat
message in the conversation panel, so if weird stuff happens, such as
chat message that are badly formatted or contain weird characters, let
me know.

Kind regards,
Danny

On 08/29/2014 12:16 PM, Yana Stamcheva wrote:

Hi Danny,

On 28 Aug 2014, at 22:28, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Hi all,

I am planning to merge a modified implementation of the message
formatting code that processes message that are about to be displayed in
the chat conversation window. This code improves on the following aspects:

1. A different approach to handling (mixed) plain text and html
messages. I process the plain text message once, strictly leveraging the
fact that the code knows exactly when text is plain text and when it
gets turned into HTML (i.e. at least partially formatted for displaying
already).

2. Not using <plaintext> tags anymore, since these cancel any active
formatting, such as light-grey from system messages, headings and such.

3. Strict HTML escaping for any text that should be displayed as is,
this includes names of chat rooms, members and subjects. This is
important since IRC channel names allow for almost any character, so you
can create a small HTML document as a chat room name, and we'd like to
prevent HTML injection.

4. Now that <plaintext> tags are gone, I've taken a different approach
to processing messages based on the plain text parts of the message:
this approach searches for text in between the HTML tags for processing
and escapes it automatically such that you can process based on the
original content, instead of the HTML-escaped content.

5. Separate implementations, based on a public interface for the
preprocessing steps that are executed on all incoming messages. There is
an interface called 'Replacer' for which a number of implementations
exist that were previously available as individual methods. (A separate
package is created for these implementations.)

6. Fixed processing URL's in HTML text. (This previously only worked for
discovering hyperlinks in plain text message.)

7. Fixed ordering of processing keywords vs. hyperlinks: previously if a
keyword was highlighted, it would break the URL and the URL wouldn't be
recognized as such any more.

8. And finally, I've improved to regexp that searches for plain text
content to recognize both tags (by <> brackets) and attribute values by
quotes (") such that we can quite reliably distinguish parts from HTML
tags from actual text content.

I plan to push these changes by tomorrow evening if there are no
objections. I'd like to give you all a chance to respond beforehand,
because this touches some quite significant code. If I need to wait to
do some more testing, I'm also fine with that.

All these changes sound really great!! However as you said they touch a significant part of the code and may need an extended testing before pushing. Quite a lot of people use the unstable branch of jitsi, so I suggest that we create a branch and make sure all developers and other interested contributors use this branch for a week or so, before pushing to unstable.

You can find the code at
https://github.com/cobratbq/jitsi/commits/fix-message-formatting

Will have a look. Thanks!

Any feedback is welcome!

I'll move to your branch for my everyday use of Jitsi as soon as you create it.

Cheers,
Yana

Kind regards,
Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#8

Hi Emil,

Hey Danny,

I know a few people were on vacation (or in hospital) last week so
this hasn't really been tested that much. It's a rather substantial
change so let's not rush it ... especially if you don't have the time
to worry about it.

I agree that we shouldn't rush it. But, I think people might be
overestimating the amount of changes I've made. For example, the
"replacers" are 1:1 the same code. (just moved to the "replacers"
package and now implementing the Replacer interface) And I've made some
things explicit such as calling the message HTML after it has been
formatted.

I believe that the way I find plain text in between HTML tags is the
biggest change. (Not to excuse anything, just to point out where
weaknesses might be ... ) Because of this, we may be processing slightly
more content than previously, though I haven't noticed it in daily use.

On a side note I have noticed that unregistering an IRC account from
the accounts panel and then registering it again seems to leave you
with two instances. Have you seen this?

Hmm... no, not that I can recall. Do you mean 2 instances of
connections, or something visually in the UI?
In any case I'll play around with registering-unregistering a bit to see
what I can find.

Also, right clicking on a channel and selecting "join" seems to often
fail for me whe double clicking the channel usually works. Does this
sound familiar?

Actually, I don't have a clue. I would expect the same code to be called
here. Again, putting it on my TODO list.

Kind regards,
Danny

···

On 09/14/2014 11:37 PM, Emil Ivov wrote:

--sent from my mobile

On 14 Sep 2014 9:45 PM, "Danny van Heumen" <danny@dannyvanheumen.nl > <mailto:danny@dannyvanheumen.nl>> wrote:

    Hi all,

    So, has anyone had any problems while testing the new formatting code?

    I'd like to merge this shortly if possible, since otherwise it'll keep
    dragging on. I haven't heard of anyone having issues, so far, and I
    haven't noticed anything myself.

    Kind regards,
    Danny

    On 08/28/2014 10:28 PM, Danny van Heumen wrote:
    > Hi all,
    >
    > I am planning to merge a modified implementation of the message
    > formatting code that processes message that are about to be
    displayed in
    > the chat conversation window. This code improves on the
    following aspects:
    >
    > 1. A different approach to handling (mixed) plain text and html
    > messages. I process the plain text message once, strictly
    leveraging the
    > fact that the code knows exactly when text is plain text and when it
    > gets turned into HTML (i.e. at least partially formatted for
    displaying
    > already).
    >
    > 2. Not using <plaintext> tags anymore, since these cancel any active
    > formatting, such as light-grey from system messages, headings
    and such.
    >
    > 3. Strict HTML escaping for any text that should be displayed as is,
    > this includes names of chat rooms, members and subjects. This is
    > important since IRC channel names allow for almost any
    character, so you
    > can create a small HTML document as a chat room name, and we'd
    like to
    > prevent HTML injection.
    >
    > 4. Now that <plaintext> tags are gone, I've taken a different
    approach
    > to processing messages based on the plain text parts of the message:
    > this approach searches for text in between the HTML tags for
    processing
    > and escapes it automatically such that you can process based on the
    > original content, instead of the HTML-escaped content.
    >
    > 5. Separate implementations, based on a public interface for the
    > preprocessing steps that are executed on all incoming messages.
    There is
    > an interface called 'Replacer' for which a number of implementations
    > exist that were previously available as individual methods. (A
    separate
    > package is created for these implementations.)
    >
    > 6. Fixed processing URL's in HTML text. (This previously only
    worked for
    > discovering hyperlinks in plain text message.)
    >
    > 7. Fixed ordering of processing keywords vs. hyperlinks:
    previously if a
    > keyword was highlighted, it would break the URL and the URL
    wouldn't be
    > recognized as such any more.
    >
    > 8. And finally, I've improved to regexp that searches for plain text
    > content to recognize both tags (by <> brackets) and attribute
    values by
    > quotes (") such that we can quite reliably distinguish parts
    from HTML
    > tags from actual text content.
    >
    > I plan to push these changes by tomorrow evening if there are no
    > objections. I'd like to give you all a chance to respond beforehand,
    > because this touches some quite significant code. If I need to
    wait to
    > do some more testing, I'm also fine with that.
    >
    > You can find the code at
    > https://github.com/cobratbq/jitsi/commits/fix-message-formatting
    > Any feedback is welcome!
    >
    > Kind regards,
    > Danny
    >
    >
    >
    >
    >
    >
    > _______________________________________________
    > dev mailing list
    > dev@jitsi.org <mailto:dev@jitsi.org>
    > Unsubscribe instructions and other list options:
    > http://lists.jitsi.org/mailman/listinfo/dev
    >
    >

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#9

Hey Danny,

Hi Emil,

Hey Danny,

I know a few people were on vacation (or in hospital) last week so
this hasn't really been tested that much. It's a rather substantial
change so let's not rush it ... especially if you don't have the time
to worry about it.

I agree that we shouldn't rush it. But, I think people might be
overestimating the amount of changes I've made. For example, the
"replacers" are 1:1 the same code. (just moved to the "replacers"
package and now implementing the Replacer interface) And I've made some
things explicit such as calling the message HTML after it has been
formatted.

I believe that the way I find plain text in between HTML tags is the
biggest change. (Not to excuse anything, just to point out where
weaknesses might be ... ) Because of this, we may be processing slightly
more content than previously, though I haven't noticed it in daily use.

Damencho, Yana, could you please have a look when possible?

On a side note I have noticed that unregistering an IRC account from
the accounts panel and then registering it again seems to leave you
with two instances. Have you seen this?

Hmm... no, not that I can recall. Do you mean 2 instances of
connections, or something visually in the UI?

Yes I see it appearing twice in the status combo box on top of the
search field. I am now seeing that I can't reproduce this reliably
though ... maybe it only happens after a standby? I'll keep observing.

In any case I'll play around with registering-unregistering a bit to see
what I can find.

Also, right clicking on a channel and selecting "join" seems to often
fail for me whe double clicking the channel usually works. Does this
sound familiar?

Actually, I don't have a clue. I would expect the same code to be called
here. Again, putting it on my TODO list.

This is what I see when right clicking:

20:12:58.557 INFO: [1160]
impl.protocol.irc.ChatRoomIrcImpl.setUserNickname().687 Setting a nick
name for an individual chat room is not supported for IRC.
20:12:58.557 SEVERE: [1160]
com.ircclouds.irc.api.IRCApiImpl.executeAsync() Error executing
command
java.nio.channels.ClosedChannelException
    at sun.nio.ch.SocketChannelImpl.ensureReadOpen(SocketChannelImpl.java:122)
    at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:165)
    at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.tryReadAndUnwrap(SSLSocketChannelConnection.java:146)
    at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.processHandshake(SSLSocketChannelConnection.java:123)
    at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.doAnyPendingHandshake(SSLSocketChannelConnection.java:106)
    at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.write(SSLSocketChannelConnection.java:67)
    at com.ircclouds.irc.api.AbstractCommandServerImpl.execute(AbstractCommandServerImpl.java:19)
    at com.ircclouds.irc.api.IRCApiImpl.executeAsync(IRCApiImpl.java:593)
    at com.ircclouds.irc.api.IRCApiImpl.joinChannel(IRCApiImpl.java:176)
    at net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:639)
    at net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:581)
    at net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.join(ChatRoomIrcImpl.java:323)
    at net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.joinAs(ChatRoomIrcImpl.java:356)
    at net.java.sip.communicator.impl.muc.MUCServiceImpl$JoinChatRoomTask.run(MUCServiceImpl.java:680)

It might be a consequence of a different sequence of method calls in
one case and in the other ... have no idea.

Emil

···

On Mon, Sep 15, 2014 at 7:52 PM, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

On 09/14/2014 11:37 PM, Emil Ivov wrote:

--sent from my mobile

On 14 Sep 2014 9:45 PM, "Danny van Heumen" <danny@dannyvanheumen.nl >> <mailto:danny@dannyvanheumen.nl>> wrote:

    Hi all,

    So, has anyone had any problems while testing the new formatting code?

    I'd like to merge this shortly if possible, since otherwise it'll keep
    dragging on. I haven't heard of anyone having issues, so far, and I
    haven't noticed anything myself.

    Kind regards,
    Danny

    On 08/28/2014 10:28 PM, Danny van Heumen wrote:
    > Hi all,
    >
    > I am planning to merge a modified implementation of the message
    > formatting code that processes message that are about to be
    displayed in
    > the chat conversation window. This code improves on the
    following aspects:
    >
    > 1. A different approach to handling (mixed) plain text and html
    > messages. I process the plain text message once, strictly
    leveraging the
    > fact that the code knows exactly when text is plain text and when it
    > gets turned into HTML (i.e. at least partially formatted for
    displaying
    > already).
    >
    > 2. Not using <plaintext> tags anymore, since these cancel any active
    > formatting, such as light-grey from system messages, headings
    and such.
    >
    > 3. Strict HTML escaping for any text that should be displayed as is,
    > this includes names of chat rooms, members and subjects. This is
    > important since IRC channel names allow for almost any
    character, so you
    > can create a small HTML document as a chat room name, and we'd
    like to
    > prevent HTML injection.
    >
    > 4. Now that <plaintext> tags are gone, I've taken a different
    approach
    > to processing messages based on the plain text parts of the message:
    > this approach searches for text in between the HTML tags for
    processing
    > and escapes it automatically such that you can process based on the
    > original content, instead of the HTML-escaped content.
    >
    > 5. Separate implementations, based on a public interface for the
    > preprocessing steps that are executed on all incoming messages.
    There is
    > an interface called 'Replacer' for which a number of implementations
    > exist that were previously available as individual methods. (A
    separate
    > package is created for these implementations.)
    >
    > 6. Fixed processing URL's in HTML text. (This previously only
    worked for
    > discovering hyperlinks in plain text message.)
    >
    > 7. Fixed ordering of processing keywords vs. hyperlinks:
    previously if a
    > keyword was highlighted, it would break the URL and the URL
    wouldn't be
    > recognized as such any more.
    >
    > 8. And finally, I've improved to regexp that searches for plain text
    > content to recognize both tags (by <> brackets) and attribute
    values by
    > quotes (") such that we can quite reliably distinguish parts
    from HTML
    > tags from actual text content.
    >
    > I plan to push these changes by tomorrow evening if there are no
    > objections. I'd like to give you all a chance to respond beforehand,
    > because this touches some quite significant code. If I need to
    wait to
    > do some more testing, I'm also fine with that.
    >
    > You can find the code at
    > https://github.com/cobratbq/jitsi/commits/fix-message-formatting
    > Any feedback is welcome!
    >
    > Kind regards,
    > Danny
    >
    >
    >
    >
    >
    >
    > _______________________________________________
    > dev mailing list
    > dev@jitsi.org <mailto:dev@jitsi.org>
    > Unsubscribe instructions and other list options:
    > http://lists.jitsi.org/mailman/listinfo/dev
    >
    >

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#10

Hi Emil,

Hey Danny,

Hi Emil,

Hey Danny,

I know a few people were on vacation (or in hospital) last week so
this hasn't really been tested that much. It's a rather substantial
change so let's not rush it ... especially if you don't have the time
to worry about it.

I agree that we shouldn't rush it. But, I think people might be
overestimating the amount of changes I've made. For example, the
"replacers" are 1:1 the same code. (just moved to the "replacers"
package and now implementing the Replacer interface) And I've made some
things explicit such as calling the message HTML after it has been
formatted.

I believe that the way I find plain text in between HTML tags is the
biggest change. (Not to excuse anything, just to point out where
weaknesses might be ... ) Because of this, we may be processing slightly
more content than previously, though I haven't noticed it in daily use.

Damencho, Yana, could you please have a look when possible?

On a side note I have noticed that unregistering an IRC account from
the accounts panel and then registering it again seems to leave you
with two instances. Have you seen this?

Hmm... no, not that I can recall. Do you mean 2 instances of
connections, or something visually in the UI?

Yes I see it appearing twice in the status combo box on top of the
search field. I am now seeing that I can't reproduce this reliably
though ... maybe it only happens after a standby? I'll keep observing.

Okay, I will have a look. I myself hardly ever suspend my system. I've
already fixed 2 small bugs since damencho gave me the idea of looking
for bugs after returning from suspension. I haven't noticed this
behaviour, now that I know where to look for, I'll see what I can do.

In any case I'll play around with registering-unregistering a bit to see
what I can find.

Also, right clicking on a channel and selecting "join" seems to often
fail for me whe double clicking the channel usually works. Does this
sound familiar?

Actually, I don't have a clue. I would expect the same code to be called
here. Again, putting it on my TODO list.

This is what I see when right clicking:

20:12:58.557 INFO: [1160]
impl.protocol.irc.ChatRoomIrcImpl.setUserNickname().687 Setting a nick
name for an individual chat room is not supported for IRC.
20:12:58.557 SEVERE: [1160]
com.ircclouds.irc.api.IRCApiImpl.executeAsync() Error executing
command
java.nio.channels.ClosedChannelException
    at sun.nio.ch.SocketChannelImpl.ensureReadOpen(SocketChannelImpl.java:122)
    at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:165)
    at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.tryReadAndUnwrap(SSLSocketChannelConnection.java:146)
    at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.processHandshake(SSLSocketChannelConnection.java:123)
    at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.doAnyPendingHandshake(SSLSocketChannelConnection.java:106)
    at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.write(SSLSocketChannelConnection.java:67)
    at com.ircclouds.irc.api.AbstractCommandServerImpl.execute(AbstractCommandServerImpl.java:19)
    at com.ircclouds.irc.api.IRCApiImpl.executeAsync(IRCApiImpl.java:593)
    at com.ircclouds.irc.api.IRCApiImpl.joinChannel(IRCApiImpl.java:176)
    at net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:639)
    at net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:581)
    at net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.join(ChatRoomIrcImpl.java:323)
    at net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.joinAs(ChatRoomIrcImpl.java:356)
    at net.java.sip.communicator.impl.muc.MUCServiceImpl$JoinChatRoomTask.run(MUCServiceImpl.java:680)

It might be a consequence of a different sequence of method calls in
one case and in the other ... have no idea.

Nah, this one's easy. This is by design, actually by the design of the
author of irc-api. He has already silenced (well, lowered to DEBUG
logging level, I believe) this in a newer revision of irc-api, by my
request. He uses this as a short-cut to terminate the worker thread -
that handles the IRC connection - upon disconnecting. The exception
occurs when the disconnect is issued, so this is a consequence of
disposing of the thread.

I'd like to update irc-api to a new version shortly which contains this
fix, together with the patch to generate an OSGi bundle and (hopefully)
a fix for the buffer overflow error when we issue a lot of IRC commands
simultaneously. So that should fix a bunch of small things.

Kind regards,
Danny

···

On 09/15/2014 08:22 PM, Emil Ivov wrote:

On Mon, Sep 15, 2014 at 7:52 PM, Danny van Heumen > <danny@dannyvanheumen.nl> wrote:

On 09/14/2014 11:37 PM, Emil Ivov wrote:

Emil

--sent from my mobile

On 14 Sep 2014 9:45 PM, "Danny van Heumen" <danny@dannyvanheumen.nl >>> <mailto:danny@dannyvanheumen.nl>> wrote:

    Hi all,

    So, has anyone had any problems while testing the new formatting code?

    I'd like to merge this shortly if possible, since otherwise it'll keep
    dragging on. I haven't heard of anyone having issues, so far, and I
    haven't noticed anything myself.

    Kind regards,
    Danny

    On 08/28/2014 10:28 PM, Danny van Heumen wrote:
    > Hi all,
    >
    > I am planning to merge a modified implementation of the message
    > formatting code that processes message that are about to be
    displayed in
    > the chat conversation window. This code improves on the
    following aspects:
    >
    > 1. A different approach to handling (mixed) plain text and html
    > messages. I process the plain text message once, strictly
    leveraging the
    > fact that the code knows exactly when text is plain text and when it
    > gets turned into HTML (i.e. at least partially formatted for
    displaying
    > already).
    >
    > 2. Not using <plaintext> tags anymore, since these cancel any active
    > formatting, such as light-grey from system messages, headings
    and such.
    >
    > 3. Strict HTML escaping for any text that should be displayed as is,
    > this includes names of chat rooms, members and subjects. This is
    > important since IRC channel names allow for almost any
    character, so you
    > can create a small HTML document as a chat room name, and we'd
    like to
    > prevent HTML injection.
    >
    > 4. Now that <plaintext> tags are gone, I've taken a different
    approach
    > to processing messages based on the plain text parts of the message:
    > this approach searches for text in between the HTML tags for
    processing
    > and escapes it automatically such that you can process based on the
    > original content, instead of the HTML-escaped content.
    >
    > 5. Separate implementations, based on a public interface for the
    > preprocessing steps that are executed on all incoming messages.
    There is
    > an interface called 'Replacer' for which a number of implementations
    > exist that were previously available as individual methods. (A
    separate
    > package is created for these implementations.)
    >
    > 6. Fixed processing URL's in HTML text. (This previously only
    worked for
    > discovering hyperlinks in plain text message.)
    >
    > 7. Fixed ordering of processing keywords vs. hyperlinks:
    previously if a
    > keyword was highlighted, it would break the URL and the URL
    wouldn't be
    > recognized as such any more.
    >
    > 8. And finally, I've improved to regexp that searches for plain text
    > content to recognize both tags (by <> brackets) and attribute
    values by
    > quotes (") such that we can quite reliably distinguish parts
    from HTML
    > tags from actual text content.
    >
    > I plan to push these changes by tomorrow evening if there are no
    > objections. I'd like to give you all a chance to respond beforehand,
    > because this touches some quite significant code. If I need to
    wait to
    > do some more testing, I'm also fine with that.
    >
    > You can find the code at
    > https://github.com/cobratbq/jitsi/commits/fix-message-formatting
    > Any feedback is welcome!
    >
    > Kind regards,
    > Danny
    >
    >
    >
    >
    >
    >
    > _______________________________________________
    > dev mailing list
    > dev@jitsi.org <mailto:dev@jitsi.org>
    > Unsubscribe instructions and other list options:
    > http://lists.jitsi.org/mailman/listinfo/dev
    >
    >

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#11

Hi Emil,

I've fixed the issue with right-click-join not working. It was due to
some inconsistent UI behaviour.

Let me know if you have another clue for your issue with 2 IRC
connection instances. I haven't encountered it before, so without
additional info I'm kinda dead in the water.

Kind regards,
Danny

···

On 09/15/2014 08:22 PM, Emil Ivov wrote:

Hey Danny,

On Mon, Sep 15, 2014 at 7:52 PM, Danny van Heumen > <danny@dannyvanheumen.nl> wrote:

Hi Emil,

On 09/14/2014 11:37 PM, Emil Ivov wrote:

Hey Danny,

I know a few people were on vacation (or in hospital) last week so
this hasn't really been tested that much. It's a rather substantial
change so let's not rush it ... especially if you don't have the time
to worry about it.

I agree that we shouldn't rush it. But, I think people might be
overestimating the amount of changes I've made. For example, the
"replacers" are 1:1 the same code. (just moved to the "replacers"
package and now implementing the Replacer interface) And I've made some
things explicit such as calling the message HTML after it has been
formatted.

I believe that the way I find plain text in between HTML tags is the
biggest change. (Not to excuse anything, just to point out where
weaknesses might be ... ) Because of this, we may be processing slightly
more content than previously, though I haven't noticed it in daily use.

Damencho, Yana, could you please have a look when possible?

On a side note I have noticed that unregistering an IRC account from
the accounts panel and then registering it again seems to leave you
with two instances. Have you seen this?

Hmm... no, not that I can recall. Do you mean 2 instances of
connections, or something visually in the UI?

Yes I see it appearing twice in the status combo box on top of the
search field. I am now seeing that I can't reproduce this reliably
though ... maybe it only happens after a standby? I'll keep observing.

In any case I'll play around with registering-unregistering a bit to see
what I can find.

Also, right clicking on a channel and selecting "join" seems to often
fail for me whe double clicking the channel usually works. Does this
sound familiar?

Actually, I don't have a clue. I would expect the same code to be called
here. Again, putting it on my TODO list.

This is what I see when right clicking:

20:12:58.557 INFO: [1160]
impl.protocol.irc.ChatRoomIrcImpl.setUserNickname().687 Setting a nick
name for an individual chat room is not supported for IRC.
20:12:58.557 SEVERE: [1160]
com.ircclouds.irc.api.IRCApiImpl.executeAsync() Error executing
command
java.nio.channels.ClosedChannelException
    at sun.nio.ch.SocketChannelImpl.ensureReadOpen(SocketChannelImpl.java:122)
    at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:165)
    at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.tryReadAndUnwrap(SSLSocketChannelConnection.java:146)
    at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.processHandshake(SSLSocketChannelConnection.java:123)
    at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.doAnyPendingHandshake(SSLSocketChannelConnection.java:106)
    at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.write(SSLSocketChannelConnection.java:67)
    at com.ircclouds.irc.api.AbstractCommandServerImpl.execute(AbstractCommandServerImpl.java:19)
    at com.ircclouds.irc.api.IRCApiImpl.executeAsync(IRCApiImpl.java:593)
    at com.ircclouds.irc.api.IRCApiImpl.joinChannel(IRCApiImpl.java:176)
    at net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:639)
    at net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:581)
    at net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.join(ChatRoomIrcImpl.java:323)
    at net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.joinAs(ChatRoomIrcImpl.java:356)
    at net.java.sip.communicator.impl.muc.MUCServiceImpl$JoinChatRoomTask.run(MUCServiceImpl.java:680)

It might be a consequence of a different sequence of method calls in
one case and in the other ... have no idea.

Emil

--sent from my mobile

On 14 Sep 2014 9:45 PM, "Danny van Heumen" <danny@dannyvanheumen.nl >>> <mailto:danny@dannyvanheumen.nl>> wrote:

    Hi all,

    So, has anyone had any problems while testing the new formatting code?

    I'd like to merge this shortly if possible, since otherwise it'll keep
    dragging on. I haven't heard of anyone having issues, so far, and I
    haven't noticed anything myself.

    Kind regards,
    Danny

    On 08/28/2014 10:28 PM, Danny van Heumen wrote:
    > Hi all,
    >
    > I am planning to merge a modified implementation of the message
    > formatting code that processes message that are about to be
    displayed in
    > the chat conversation window. This code improves on the
    following aspects:
    >
    > 1. A different approach to handling (mixed) plain text and html
    > messages. I process the plain text message once, strictly
    leveraging the
    > fact that the code knows exactly when text is plain text and when it
    > gets turned into HTML (i.e. at least partially formatted for
    displaying
    > already).
    >
    > 2. Not using <plaintext> tags anymore, since these cancel any active
    > formatting, such as light-grey from system messages, headings
    and such.
    >
    > 3. Strict HTML escaping for any text that should be displayed as is,
    > this includes names of chat rooms, members and subjects. This is
    > important since IRC channel names allow for almost any
    character, so you
    > can create a small HTML document as a chat room name, and we'd
    like to
    > prevent HTML injection.
    >
    > 4. Now that <plaintext> tags are gone, I've taken a different
    approach
    > to processing messages based on the plain text parts of the message:
    > this approach searches for text in between the HTML tags for
    processing
    > and escapes it automatically such that you can process based on the
    > original content, instead of the HTML-escaped content.
    >
    > 5. Separate implementations, based on a public interface for the
    > preprocessing steps that are executed on all incoming messages.
    There is
    > an interface called 'Replacer' for which a number of implementations
    > exist that were previously available as individual methods. (A
    separate
    > package is created for these implementations.)
    >
    > 6. Fixed processing URL's in HTML text. (This previously only
    worked for
    > discovering hyperlinks in plain text message.)
    >
    > 7. Fixed ordering of processing keywords vs. hyperlinks:
    previously if a
    > keyword was highlighted, it would break the URL and the URL
    wouldn't be
    > recognized as such any more.
    >
    > 8. And finally, I've improved to regexp that searches for plain text
    > content to recognize both tags (by <> brackets) and attribute
    values by
    > quotes (") such that we can quite reliably distinguish parts
    from HTML
    > tags from actual text content.
    >
    > I plan to push these changes by tomorrow evening if there are no
    > objections. I'd like to give you all a chance to respond beforehand,
    > because this touches some quite significant code. If I need to
    wait to
    > do some more testing, I'm also fine with that.
    >
    > You can find the code at
    > https://github.com/cobratbq/jitsi/commits/fix-message-formatting
    > Any feedback is welcome!
    >
    > Kind regards,
    > Danny
    >
    >
    >
    >
    >
    >
    > _______________________________________________
    > dev mailing list
    > dev@jitsi.org <mailto:dev@jitsi.org>
    > Unsubscribe instructions and other list options:
    > http://lists.jitsi.org/mailman/listinfo/dev
    >
    >

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#12

Hi Danny, Emil,

Hi Emil,

Hey Danny,

Hi Emil,

Hey Danny,

I know a few people were on vacation (or in hospital) last week so
this hasn't really been tested that much. It's a rather substantial
change so let's not rush it ... especially if you don't have the time
to worry about it.

I agree that we shouldn't rush it. But, I think people might be
overestimating the amount of changes I've made. For example, the
"replacers" are 1:1 the same code. (just moved to the "replacers"
package and now implementing the Replacer interface) And I've made some
things explicit such as calling the message HTML after it has been
formatted.

I believe that the way I find plain text in between HTML tags is the
biggest change. (Not to excuse anything, just to point out where
weaknesses might be ... ) Because of this, we may be processing slightly
more content than previously, though I haven't noticed it in daily use.

Damencho, Yana, could you please have a look when possible?

I'm sorry I couldn't respond earlier, I've had very intermittent access to internet and a computer for the past week.

I've thoroughly tested all chat features (image replacements, history back/forward, html messages, last message correction, group chat, etc.) on your branch today and everything seems to work very smoothly!

Damian would confirm that, but he already mentioned to me off-list today that he has used your branch for a few days and haven't seen any issues with it.

Thanks for the patience. I think you could go ahead with the commit.

Cheers,
Yana

···

On 15 Sep 2014, at 20:47, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

On 09/15/2014 08:22 PM, Emil Ivov wrote:

On Mon, Sep 15, 2014 at 7:52 PM, Danny van Heumen >> <danny@dannyvanheumen.nl> wrote:

On 09/14/2014 11:37 PM, Emil Ivov wrote:

On a side note I have noticed that unregistering an IRC account from
the accounts panel and then registering it again seems to leave you
with two instances. Have you seen this?

Hmm... no, not that I can recall. Do you mean 2 instances of
connections, or something visually in the UI?

Yes I see it appearing twice in the status combo box on top of the
search field. I am now seeing that I can't reproduce this reliably
though ... maybe it only happens after a standby? I'll keep observing.

Okay, I will have a look. I myself hardly ever suspend my system. I've
already fixed 2 small bugs since damencho gave me the idea of looking
for bugs after returning from suspension. I haven't noticed this
behaviour, now that I know where to look for, I'll see what I can do.

In any case I'll play around with registering-unregistering a bit to see
what I can find.

Also, right clicking on a channel and selecting "join" seems to often
fail for me whe double clicking the channel usually works. Does this
sound familiar?

Actually, I don't have a clue. I would expect the same code to be called
here. Again, putting it on my TODO list.

This is what I see when right clicking:

20:12:58.557 INFO: [1160]
impl.protocol.irc.ChatRoomIrcImpl.setUserNickname().687 Setting a nick
name for an individual chat room is not supported for IRC.
20:12:58.557 SEVERE: [1160]
com.ircclouds.irc.api.IRCApiImpl.executeAsync() Error executing
command
java.nio.channels.ClosedChannelException
   at sun.nio.ch.SocketChannelImpl.ensureReadOpen(SocketChannelImpl.java:122)
   at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:165)
   at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.tryReadAndUnwrap(SSLSocketChannelConnection.java:146)
   at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.processHandshake(SSLSocketChannelConnection.java:123)
   at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.doAnyPendingHandshake(SSLSocketChannelConnection.java:106)
   at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.write(SSLSocketChannelConnection.java:67)
   at com.ircclouds.irc.api.AbstractCommandServerImpl.execute(AbstractCommandServerImpl.java:19)
   at com.ircclouds.irc.api.IRCApiImpl.executeAsync(IRCApiImpl.java:593)
   at com.ircclouds.irc.api.IRCApiImpl.joinChannel(IRCApiImpl.java:176)
   at net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:639)
   at net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:581)
   at net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.join(ChatRoomIrcImpl.java:323)
   at net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.joinAs(ChatRoomIrcImpl.java:356)
   at net.java.sip.communicator.impl.muc.MUCServiceImpl$JoinChatRoomTask.run(MUCServiceImpl.java:680)

It might be a consequence of a different sequence of method calls in
one case and in the other ... have no idea.

Nah, this one's easy. This is by design, actually by the design of the
author of irc-api. He has already silenced (well, lowered to DEBUG
logging level, I believe) this in a newer revision of irc-api, by my
request. He uses this as a short-cut to terminate the worker thread -
that handles the IRC connection - upon disconnecting. The exception
occurs when the disconnect is issued, so this is a consequence of
disposing of the thread.

I'd like to update irc-api to a new version shortly which contains this
fix, together with the patch to generate an OSGi bundle and (hopefully)
a fix for the buffer overflow error when we issue a lot of IRC commands
simultaneously. So that should fix a bunch of small things.

Kind regards,
Danny

Emil

--sent from my mobile

On 14 Sep 2014 9:45 PM, "Danny van Heumen" <danny@dannyvanheumen.nl >>>> <mailto:danny@dannyvanheumen.nl>> wrote:

   Hi all,

   So, has anyone had any problems while testing the new formatting code?

   I'd like to merge this shortly if possible, since otherwise it'll keep
   dragging on. I haven't heard of anyone having issues, so far, and I
   haven't noticed anything myself.

   Kind regards,
   Danny

   On 08/28/2014 10:28 PM, Danny van Heumen wrote:

Hi all,

I am planning to merge a modified implementation of the message
formatting code that processes message that are about to be

   displayed in

the chat conversation window. This code improves on the

   following aspects:

1. A different approach to handling (mixed) plain text and html
messages. I process the plain text message once, strictly

   leveraging the

fact that the code knows exactly when text is plain text and when it
gets turned into HTML (i.e. at least partially formatted for

   displaying

already).

2. Not using <plaintext> tags anymore, since these cancel any active
formatting, such as light-grey from system messages, headings

   and such.

3. Strict HTML escaping for any text that should be displayed as is,
this includes names of chat rooms, members and subjects. This is
important since IRC channel names allow for almost any

   character, so you

can create a small HTML document as a chat room name, and we'd

   like to

prevent HTML injection.

4. Now that <plaintext> tags are gone, I've taken a different

   approach

to processing messages based on the plain text parts of the message:
this approach searches for text in between the HTML tags for

   processing

and escapes it automatically such that you can process based on the
original content, instead of the HTML-escaped content.

5. Separate implementations, based on a public interface for the
preprocessing steps that are executed on all incoming messages.

   There is

an interface called 'Replacer' for which a number of implementations
exist that were previously available as individual methods. (A

   separate

package is created for these implementations.)

6. Fixed processing URL's in HTML text. (This previously only

   worked for

discovering hyperlinks in plain text message.)

7. Fixed ordering of processing keywords vs. hyperlinks:

   previously if a

keyword was highlighted, it would break the URL and the URL

   wouldn't be

recognized as such any more.

8. And finally, I've improved to regexp that searches for plain text
content to recognize both tags (by <> brackets) and attribute

   values by

quotes (") such that we can quite reliably distinguish parts

   from HTML

tags from actual text content.

I plan to push these changes by tomorrow evening if there are no
objections. I'd like to give you all a chance to respond beforehand,
because this touches some quite significant code. If I need to

   wait to

do some more testing, I'm also fine with that.

You can find the code at
https://github.com/cobratbq/jitsi/commits/fix-message-formatting
Any feedback is welcome!

Kind regards,
Danny

_______________________________________________
dev mailing list
dev@jitsi.org <mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

   _______________________________________________
   dev mailing list
   dev@jitsi.org <mailto:dev@jitsi.org>
   Unsubscribe instructions and other list options:
   http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#13

Awesome! Thanks Danny! Will do!

In the mean time, have you tried clicking the account checkbox multiple
times in a row? I noticed something else there as well: chat rooms are
being duplicated every time you do that. Now I am wondering if this is
exclusive to IRC though.

I also get the duplicated account fairly often too. I'll see if I can get
you more detail (did I already send you an exception stack trace btw?)

--sent from my mobile

···

On 17 Sep 2014 9:36 PM, "Danny van Heumen" <danny@dannyvanheumen.nl> wrote:

Hi Emil,

I've fixed the issue with right-click-join not working. It was due to
some inconsistent UI behaviour.

Let me know if you have another clue for your issue with 2 IRC
connection instances. I haven't encountered it before, so without
additional info I'm kinda dead in the water.

Kind regards,
Danny

On 09/15/2014 08:22 PM, Emil Ivov wrote:
> Hey Danny,
>
> On Mon, Sep 15, 2014 at 7:52 PM, Danny van Heumen > > <danny@dannyvanheumen.nl> wrote:
>> Hi Emil,
>>
>> On 09/14/2014 11:37 PM, Emil Ivov wrote:
>>> Hey Danny,
>>>
>>> I know a few people were on vacation (or in hospital) last week so
>>> this hasn't really been tested that much. It's a rather substantial
>>> change so let's not rush it ... especially if you don't have the time
>>> to worry about it.
>>>
>> I agree that we shouldn't rush it. But, I think people might be
>> overestimating the amount of changes I've made. For example, the
>> "replacers" are 1:1 the same code. (just moved to the "replacers"
>> package and now implementing the Replacer interface) And I've made some
>> things explicit such as calling the message HTML after it has been
>> formatted.
>>
>> I believe that the way I find plain text in between HTML tags is the
>> biggest change. (Not to excuse anything, just to point out where
>> weaknesses might be ... ) Because of this, we may be processing slightly
>> more content than previously, though I haven't noticed it in daily use.
> Damencho, Yana, could you please have a look when possible?
>
>>> On a side note I have noticed that unregistering an IRC account from
>>> the accounts panel and then registering it again seems to leave you
>>> with two instances. Have you seen this?
>>>
>> Hmm... no, not that I can recall. Do you mean 2 instances of
>> connections, or something visually in the UI?
> Yes I see it appearing twice in the status combo box on top of the
> search field. I am now seeing that I can't reproduce this reliably
> though ... maybe it only happens after a standby? I'll keep observing.
>
>> In any case I'll play around with registering-unregistering a bit to see
>> what I can find.
>>
>>> Also, right clicking on a channel and selecting "join" seems to often
>>> fail for me whe double clicking the channel usually works. Does this
>>> sound familiar?
>>>
>> Actually, I don't have a clue. I would expect the same code to be called
>> here. Again, putting it on my TODO list.
> This is what I see when right clicking:
>
> 20:12:58.557 INFO: [1160]
> impl.protocol.irc.ChatRoomIrcImpl.setUserNickname().687 Setting a nick
> name for an individual chat room is not supported for IRC.
> 20:12:58.557 SEVERE: [1160]
> com.ircclouds.irc.api.IRCApiImpl.executeAsync() Error executing
> command
> java.nio.channels.ClosedChannelException
> at
sun.nio.ch.SocketChannelImpl.ensureReadOpen(SocketChannelImpl.java:122)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:165)
> at
com.ircclouds.irc.api.comms.SSLSocketChannelConnection.tryReadAndUnwrap(SSLSocketChannelConnection.java:146)
> at
com.ircclouds.irc.api.comms.SSLSocketChannelConnection.processHandshake(SSLSocketChannelConnection.java:123)
> at
com.ircclouds.irc.api.comms.SSLSocketChannelConnection.doAnyPendingHandshake(SSLSocketChannelConnection.java:106)
> at
com.ircclouds.irc.api.comms.SSLSocketChannelConnection.write(SSLSocketChannelConnection.java:67)
> at
com.ircclouds.irc.api.AbstractCommandServerImpl.execute(AbstractCommandServerImpl.java:19)
> at com.ircclouds.irc.api.IRCApiImpl.executeAsync(IRCApiImpl.java:593)
> at com.ircclouds.irc.api.IRCApiImpl.joinChannel(IRCApiImpl.java:176)
> at
net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:639)
> at
net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:581)
> at
net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.join(ChatRoomIrcImpl.java:323)
> at
net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.joinAs(ChatRoomIrcImpl.java:356)
> at
net.java.sip.communicator.impl.muc.MUCServiceImpl$JoinChatRoomTask.run(MUCServiceImpl.java:680)
>
> It might be a consequence of a different sequence of method calls in
> one case and in the other ... have no idea.
>
> Emil
>
>>> --sent from my mobile
>>>
>>> On 14 Sep 2014 9:45 PM, "Danny van Heumen" <danny@dannyvanheumen.nl > >>> <mailto:danny@dannyvanheumen.nl>> wrote:
>>>
>>> Hi all,
>>>
>>> So, has anyone had any problems while testing the new formatting
code?
>>>
>>> I'd like to merge this shortly if possible, since otherwise it'll
keep
>>> dragging on. I haven't heard of anyone having issues, so far, and I
>>> haven't noticed anything myself.
>>>
>>> Kind regards,
>>> Danny
>>>
>>>
>>> On 08/28/2014 10:28 PM, Danny van Heumen wrote:
>>> > Hi all,
>>> >
>>> > I am planning to merge a modified implementation of the message
>>> > formatting code that processes message that are about to be
>>> displayed in
>>> > the chat conversation window. This code improves on the
>>> following aspects:
>>> >
>>> > 1. A different approach to handling (mixed) plain text and html
>>> > messages. I process the plain text message once, strictly
>>> leveraging the
>>> > fact that the code knows exactly when text is plain text and
when it
>>> > gets turned into HTML (i.e. at least partially formatted for
>>> displaying
>>> > already).
>>> >
>>> > 2. Not using <plaintext> tags anymore, since these cancel any
active
>>> > formatting, such as light-grey from system messages, headings
>>> and such.
>>> >
>>> > 3. Strict HTML escaping for any text that should be displayed as
is,
>>> > this includes names of chat rooms, members and subjects. This is
>>> > important since IRC channel names allow for almost any
>>> character, so you
>>> > can create a small HTML document as a chat room name, and we'd
>>> like to
>>> > prevent HTML injection.
>>> >
>>> > 4. Now that <plaintext> tags are gone, I've taken a different
>>> approach
>>> > to processing messages based on the plain text parts of the
message:
>>> > this approach searches for text in between the HTML tags for
>>> processing
>>> > and escapes it automatically such that you can process based on
the
>>> > original content, instead of the HTML-escaped content.
>>> >
>>> > 5. Separate implementations, based on a public interface for the
>>> > preprocessing steps that are executed on all incoming messages.
>>> There is
>>> > an interface called 'Replacer' for which a number of
implementations
>>> > exist that were previously available as individual methods. (A
>>> separate
>>> > package is created for these implementations.)
>>> >
>>> > 6. Fixed processing URL's in HTML text. (This previously only
>>> worked for
>>> > discovering hyperlinks in plain text message.)
>>> >
>>> > 7. Fixed ordering of processing keywords vs. hyperlinks:
>>> previously if a
>>> > keyword was highlighted, it would break the URL and the URL
>>> wouldn't be
>>> > recognized as such any more.
>>> >
>>> > 8. And finally, I've improved to regexp that searches for plain
text
>>> > content to recognize both tags (by <> brackets) and attribute
>>> values by
>>> > quotes (") such that we can quite reliably distinguish parts
>>> from HTML
>>> > tags from actual text content.
>>> >
>>> > I plan to push these changes by tomorrow evening if there are no
>>> > objections. I'd like to give you all a chance to respond
beforehand,
>>> > because this touches some quite significant code. If I need to
>>> wait to
>>> > do some more testing, I'm also fine with that.
>>> >
>>> > You can find the code at
>>> > https://github.com/cobratbq/jitsi/commits/fix-message-formatting
>>> > Any feedback is welcome!
>>> >
>>> > Kind regards,
>>> > Danny
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > dev mailing list
>>> > dev@jitsi.org <mailto:dev@jitsi.org>
>>> > Unsubscribe instructions and other list options:
>>> > http://lists.jitsi.org/mailman/listinfo/dev
>>> >
>>> >
>>>
>>>
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev@jitsi.org <mailto:dev@jitsi.org>
>>> Unsubscribe instructions and other list options:
>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>
>>>
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev@jitsi.org
>>> Unsubscribe instructions and other list options:
>>> http://lists.jitsi.org/mailman/listinfo/dev
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#14

Hi Yana, damencho, Emil,

Thanks for taking the time to test this.
I've now merged this code. I'll keep an extra eye out for the coming
weeks just in case someone finds an obscure bug that we haven't found yet.

@Emil: I'm going to check how I can fix this thing with
right-click-joining a chat room. This is probably a bug in the IRC
implementation that's off with MUC expectations. (I already noticed that
it only occurs if the chat room hasn't been joined yet.)

Danny

···

On 09/15/2014 11:34 PM, Yana Stamcheva wrote:

Hi Danny, Emil,

On 15 Sep 2014, at 20:47, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Hi Emil,

On 09/15/2014 08:22 PM, Emil Ivov wrote:

Hey Danny,

On Mon, Sep 15, 2014 at 7:52 PM, Danny van Heumen >>> <danny@dannyvanheumen.nl> wrote:

Hi Emil,

On 09/14/2014 11:37 PM, Emil Ivov wrote:

Hey Danny,

I know a few people were on vacation (or in hospital) last week so
this hasn't really been tested that much. It's a rather substantial
change so let's not rush it ... especially if you don't have the time
to worry about it.

I agree that we shouldn't rush it. But, I think people might be
overestimating the amount of changes I've made. For example, the
"replacers" are 1:1 the same code. (just moved to the "replacers"
package and now implementing the Replacer interface) And I've made some
things explicit such as calling the message HTML after it has been
formatted.

I believe that the way I find plain text in between HTML tags is the
biggest change. (Not to excuse anything, just to point out where
weaknesses might be ... ) Because of this, we may be processing slightly
more content than previously, though I haven't noticed it in daily use.

Damencho, Yana, could you please have a look when possible?

I'm sorry I couldn't respond earlier, I've had very intermittent access to internet and a computer for the past week.

I've thoroughly tested all chat features (image replacements, history back/forward, html messages, last message correction, group chat, etc.) on your branch today and everything seems to work very smoothly!

Damian would confirm that, but he already mentioned to me off-list today that he has used your branch for a few days and haven't seen any issues with it.

Thanks for the patience. I think you could go ahead with the commit.

Cheers,
Yana

On a side note I have noticed that unregistering an IRC account from
the accounts panel and then registering it again seems to leave you
with two instances. Have you seen this?

Hmm... no, not that I can recall. Do you mean 2 instances of
connections, or something visually in the UI?

Yes I see it appearing twice in the status combo box on top of the
search field. I am now seeing that I can't reproduce this reliably
though ... maybe it only happens after a standby? I'll keep observing.

Okay, I will have a look. I myself hardly ever suspend my system. I've
already fixed 2 small bugs since damencho gave me the idea of looking
for bugs after returning from suspension. I haven't noticed this
behaviour, now that I know where to look for, I'll see what I can do.

In any case I'll play around with registering-unregistering a bit to see
what I can find.

Also, right clicking on a channel and selecting "join" seems to often
fail for me whe double clicking the channel usually works. Does this
sound familiar?

Actually, I don't have a clue. I would expect the same code to be called
here. Again, putting it on my TODO list.

This is what I see when right clicking:

20:12:58.557 INFO: [1160]
impl.protocol.irc.ChatRoomIrcImpl.setUserNickname().687 Setting a nick
name for an individual chat room is not supported for IRC.
20:12:58.557 SEVERE: [1160]
com.ircclouds.irc.api.IRCApiImpl.executeAsync() Error executing
command
java.nio.channels.ClosedChannelException
   at sun.nio.ch.SocketChannelImpl.ensureReadOpen(SocketChannelImpl.java:122)
   at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:165)
   at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.tryReadAndUnwrap(SSLSocketChannelConnection.java:146)
   at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.processHandshake(SSLSocketChannelConnection.java:123)
   at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.doAnyPendingHandshake(SSLSocketChannelConnection.java:106)
   at com.ircclouds.irc.api.comms.SSLSocketChannelConnection.write(SSLSocketChannelConnection.java:67)
   at com.ircclouds.irc.api.AbstractCommandServerImpl.execute(AbstractCommandServerImpl.java:19)
   at com.ircclouds.irc.api.IRCApiImpl.executeAsync(IRCApiImpl.java:593)
   at com.ircclouds.irc.api.IRCApiImpl.joinChannel(IRCApiImpl.java:176)
   at net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:639)
   at net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:581)
   at net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.join(ChatRoomIrcImpl.java:323)
   at net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.joinAs(ChatRoomIrcImpl.java:356)
   at net.java.sip.communicator.impl.muc.MUCServiceImpl$JoinChatRoomTask.run(MUCServiceImpl.java:680)

It might be a consequence of a different sequence of method calls in
one case and in the other ... have no idea.

Nah, this one's easy. This is by design, actually by the design of the
author of irc-api. He has already silenced (well, lowered to DEBUG
logging level, I believe) this in a newer revision of irc-api, by my
request. He uses this as a short-cut to terminate the worker thread -
that handles the IRC connection - upon disconnecting. The exception
occurs when the disconnect is issued, so this is a consequence of
disposing of the thread.

I'd like to update irc-api to a new version shortly which contains this
fix, together with the patch to generate an OSGi bundle and (hopefully)
a fix for the buffer overflow error when we issue a lot of IRC commands
simultaneously. So that should fix a bunch of small things.

Kind regards,
Danny

Emil

--sent from my mobile

On 14 Sep 2014 9:45 PM, "Danny van Heumen" <danny@dannyvanheumen.nl >>>>> <mailto:danny@dannyvanheumen.nl>> wrote:

   Hi all,

   So, has anyone had any problems while testing the new formatting code?

   I'd like to merge this shortly if possible, since otherwise it'll keep
   dragging on. I haven't heard of anyone having issues, so far, and I
   haven't noticed anything myself.

   Kind regards,
   Danny

   On 08/28/2014 10:28 PM, Danny van Heumen wrote:

Hi all,

I am planning to merge a modified implementation of the message
formatting code that processes message that are about to be

   displayed in

the chat conversation window. This code improves on the

   following aspects:

1. A different approach to handling (mixed) plain text and html
messages. I process the plain text message once, strictly

   leveraging the

fact that the code knows exactly when text is plain text and when it
gets turned into HTML (i.e. at least partially formatted for

   displaying

already).

2. Not using <plaintext> tags anymore, since these cancel any active
formatting, such as light-grey from system messages, headings

   and such.

3. Strict HTML escaping for any text that should be displayed as is,
this includes names of chat rooms, members and subjects. This is
important since IRC channel names allow for almost any

   character, so you

can create a small HTML document as a chat room name, and we'd

   like to

prevent HTML injection.

4. Now that <plaintext> tags are gone, I've taken a different

   approach

to processing messages based on the plain text parts of the message:
this approach searches for text in between the HTML tags for

   processing

and escapes it automatically such that you can process based on the
original content, instead of the HTML-escaped content.

5. Separate implementations, based on a public interface for the
preprocessing steps that are executed on all incoming messages.

   There is

an interface called 'Replacer' for which a number of implementations
exist that were previously available as individual methods. (A

   separate

package is created for these implementations.)

6. Fixed processing URL's in HTML text. (This previously only

   worked for

discovering hyperlinks in plain text message.)

7. Fixed ordering of processing keywords vs. hyperlinks:

   previously if a

keyword was highlighted, it would break the URL and the URL

   wouldn't be

recognized as such any more.

8. And finally, I've improved to regexp that searches for plain text
content to recognize both tags (by <> brackets) and attribute

   values by

quotes (") such that we can quite reliably distinguish parts

   from HTML

tags from actual text content.

I plan to push these changes by tomorrow evening if there are no
objections. I'd like to give you all a chance to respond beforehand,
because this touches some quite significant code. If I need to

   wait to

do some more testing, I'm also fine with that.

You can find the code at
https://github.com/cobratbq/jitsi/commits/fix-message-formatting
Any feedback is welcome!

Kind regards,
Danny

_______________________________________________
dev mailing list
dev@jitsi.org <mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

   _______________________________________________
   dev mailing list
   dev@jitsi.org <mailto:dev@jitsi.org>
   Unsubscribe instructions and other list options:
   http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#15

Hi Emil,

Awesome! Thanks Danny! Will do!

In the mean time, have you tried clicking the account checkbox
multiple times in a row? I noticed something else there as well: chat
rooms are being duplicated every time you do that. Now I am wondering
if this is exclusive to IRC though.

I think this is exclusive to IRC. I adopted the original implementation
of the IRC accregwiz almost completely unchanged. This implementation
"modifies" an account by first removing it and then adding the modified
account again. This is most likely the cause of the duplication of IRC
channels.

As for the IRC connection itself. It seems that quickly
enabling/disabling IRC seems to be too fast to properly dispose of the
irc-api instance.

I also get the duplicated account fairly often too. I'll see if I can
get you more detail (did I already send you an exception stack trace btw?)

I haven't received the exception trace yet, I believe. Also, quickly
enabling-disabling the account duplicated chat rooms, but it didn't
duplicate the account in the Options -> Accounts list, so repro recipe
is welcome.

···

On 09/18/2014 08:14 AM, Emil Ivov wrote:

--sent from my mobile

Sent from my PC.

On 17 Sep 2014 9:36 PM, "Danny van Heumen" <danny@dannyvanheumen.nl > <mailto:danny@dannyvanheumen.nl>> wrote:

    Hi Emil,

    I've fixed the issue with right-click-join not working. It was due to
    some inconsistent UI behaviour.

    Let me know if you have another clue for your issue with 2 IRC
    connection instances. I haven't encountered it before, so without
    additional info I'm kinda dead in the water.

    Kind regards,
    Danny

    On 09/15/2014 08:22 PM, Emil Ivov wrote:
    > Hey Danny,
    >
    > On Mon, Sep 15, 2014 at 7:52 PM, Danny van Heumen > > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>> wrote:
    >> Hi Emil,
    >>
    >> On 09/14/2014 11:37 PM, Emil Ivov wrote:
    >>> Hey Danny,
    >>>
    >>> I know a few people were on vacation (or in hospital) last week so
    >>> this hasn't really been tested that much. It's a rather
    substantial
    >>> change so let's not rush it ... especially if you don't have
    the time
    >>> to worry about it.
    >>>
    >> I agree that we shouldn't rush it. But, I think people might be
    >> overestimating the amount of changes I've made. For example, the
    >> "replacers" are 1:1 the same code. (just moved to the "replacers"
    >> package and now implementing the Replacer interface) And I've
    made some
    >> things explicit such as calling the message HTML after it has been
    >> formatted.
    >>
    >> I believe that the way I find plain text in between HTML tags
    is the
    >> biggest change. (Not to excuse anything, just to point out where
    >> weaknesses might be ... ) Because of this, we may be processing
    slightly
    >> more content than previously, though I haven't noticed it in
    daily use.
    > Damencho, Yana, could you please have a look when possible?
    >
    >>> On a side note I have noticed that unregistering an IRC
    account from
    >>> the accounts panel and then registering it again seems to
    leave you
    >>> with two instances. Have you seen this?
    >>>
    >> Hmm... no, not that I can recall. Do you mean 2 instances of
    >> connections, or something visually in the UI?
    > Yes I see it appearing twice in the status combo box on top of the
    > search field. I am now seeing that I can't reproduce this reliably
    > though ... maybe it only happens after a standby? I'll keep
    observing.
    >
    >> In any case I'll play around with registering-unregistering a
    bit to see
    >> what I can find.
    >>
    >>> Also, right clicking on a channel and selecting "join" seems
    to often
    >>> fail for me whe double clicking the channel usually works.
    Does this
    >>> sound familiar?
    >>>
    >> Actually, I don't have a clue. I would expect the same code to
    be called
    >> here. Again, putting it on my TODO list.
    > This is what I see when right clicking:
    >
    > 20:12:58.557 INFO: [1160]
    > impl.protocol.irc.ChatRoomIrcImpl.setUserNickname().687 Setting
    a nick
    > name for an individual chat room is not supported for IRC.
    > 20:12:58.557 SEVERE: [1160]
    > com.ircclouds.irc.api.IRCApiImpl.executeAsync() Error executing
    > command
    > java.nio.channels.ClosedChannelException
    > at
    sun.nio.ch.SocketChannelImpl.ensureReadOpen(SocketChannelImpl.java:122)
    > at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:165)
    > at
    com.ircclouds.irc.api.comms.SSLSocketChannelConnection.tryReadAndUnwrap(SSLSocketChannelConnection.java:146)
    > at
    com.ircclouds.irc.api.comms.SSLSocketChannelConnection.processHandshake(SSLSocketChannelConnection.java:123)
    > at
    com.ircclouds.irc.api.comms.SSLSocketChannelConnection.doAnyPendingHandshake(SSLSocketChannelConnection.java:106)
    > at
    com.ircclouds.irc.api.comms.SSLSocketChannelConnection.write(SSLSocketChannelConnection.java:67)
    > at
    com.ircclouds.irc.api.AbstractCommandServerImpl.execute(AbstractCommandServerImpl.java:19)
    > at
    com.ircclouds.irc.api.IRCApiImpl.executeAsync(IRCApiImpl.java:593)
    > at
    com.ircclouds.irc.api.IRCApiImpl.joinChannel(IRCApiImpl.java:176)
    > at
    net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:639)
    > at
    net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:581)
    > at
    net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.join(ChatRoomIrcImpl.java:323)
    > at
    net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.joinAs(ChatRoomIrcImpl.java:356)
    > at
    net.java.sip.communicator.impl.muc.MUCServiceImpl$JoinChatRoomTask.run(MUCServiceImpl.java:680)
    >
    > It might be a consequence of a different sequence of method calls in
    > one case and in the other ... have no idea.
    >
    > Emil
    >
    >>> --sent from my mobile
    >>>
    >>> On 14 Sep 2014 9:45 PM, "Danny van Heumen" > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl> > >>> <mailto:danny@dannyvanheumen.nl > <mailto:danny@dannyvanheumen.nl>>> wrote:
    >>>
    >>> Hi all,
    >>>
    >>> So, has anyone had any problems while testing the new
    formatting code?
    >>>
    >>> I'd like to merge this shortly if possible, since
    otherwise it'll keep
    >>> dragging on. I haven't heard of anyone having issues, so
    far, and I
    >>> haven't noticed anything myself.
    >>>
    >>> Kind regards,
    >>> Danny
    >>>
    >>>
    >>> On 08/28/2014 10:28 PM, Danny van Heumen wrote:
    >>> > Hi all,
    >>> >
    >>> > I am planning to merge a modified implementation of the
    message
    >>> > formatting code that processes message that are about to be
    >>> displayed in
    >>> > the chat conversation window. This code improves on the
    >>> following aspects:
    >>> >
    >>> > 1. A different approach to handling (mixed) plain text
    and html
    >>> > messages. I process the plain text message once, strictly
    >>> leveraging the
    >>> > fact that the code knows exactly when text is plain text
    and when it
    >>> > gets turned into HTML (i.e. at least partially formatted for
    >>> displaying
    >>> > already).
    >>> >
    >>> > 2. Not using <plaintext> tags anymore, since these
    cancel any active
    >>> > formatting, such as light-grey from system messages,
    headings
    >>> and such.
    >>> >
    >>> > 3. Strict HTML escaping for any text that should be
    displayed as is,
    >>> > this includes names of chat rooms, members and subjects.
    This is
    >>> > important since IRC channel names allow for almost any
    >>> character, so you
    >>> > can create a small HTML document as a chat room name,
    and we'd
    >>> like to
    >>> > prevent HTML injection.
    >>> >
    >>> > 4. Now that <plaintext> tags are gone, I've taken a
    different
    >>> approach
    >>> > to processing messages based on the plain text parts of
    the message:
    >>> > this approach searches for text in between the HTML tags for
    >>> processing
    >>> > and escapes it automatically such that you can process
    based on the
    >>> > original content, instead of the HTML-escaped content.
    >>> >
    >>> > 5. Separate implementations, based on a public interface
    for the
    >>> > preprocessing steps that are executed on all incoming
    messages.
    >>> There is
    >>> > an interface called 'Replacer' for which a number of
    implementations
    >>> > exist that were previously available as individual
    methods. (A
    >>> separate
    >>> > package is created for these implementations.)
    >>> >
    >>> > 6. Fixed processing URL's in HTML text. (This previously
    only
    >>> worked for
    >>> > discovering hyperlinks in plain text message.)
    >>> >
    >>> > 7. Fixed ordering of processing keywords vs. hyperlinks:
    >>> previously if a
    >>> > keyword was highlighted, it would break the URL and the URL
    >>> wouldn't be
    >>> > recognized as such any more.
    >>> >
    >>> > 8. And finally, I've improved to regexp that searches
    for plain text
    >>> > content to recognize both tags (by <> brackets) and
    attribute
    >>> values by
    >>> > quotes (") such that we can quite reliably distinguish parts
    >>> from HTML
    >>> > tags from actual text content.
    >>> >
    >>> > I plan to push these changes by tomorrow evening if
    there are no
    >>> > objections. I'd like to give you all a chance to respond
    beforehand,
    >>> > because this touches some quite significant code. If I
    need to
    >>> wait to
    >>> > do some more testing, I'm also fine with that.
    >>> >
    >>> > You can find the code at
    >>> >
    https://github.com/cobratbq/jitsi/commits/fix-message-formatting
    >>> > Any feedback is welcome!
    >>> >
    >>> > Kind regards,
    >>> > Danny
    >>> >
    >>> >
    >>> >
    >>> >
    >>> >
    >>> >
    >>> > _______________________________________________
    >>> > dev mailing list
    >>> > dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
    >>> > Unsubscribe instructions and other list options:
    >>> > http://lists.jitsi.org/mailman/listinfo/dev
    >>> >
    >>> >
    >>>
    >>>
    >>>
    >>> _______________________________________________
    >>> dev mailing list
    >>> dev@jitsi.org <mailto:dev@jitsi.org> <mailto:dev@jitsi.org
    <mailto:dev@jitsi.org>>
    >>> Unsubscribe instructions and other list options:
    >>> http://lists.jitsi.org/mailman/listinfo/dev
    >>>
    >>>
    >>>
    >>> _______________________________________________
    >>> dev mailing list
    >>> dev@jitsi.org <mailto:dev@jitsi.org>
    >>> Unsubscribe instructions and other list options:
    >>> http://lists.jitsi.org/mailman/listinfo/dev
    >>
    >>
    >> _______________________________________________
    >> dev mailing list
    >> dev@jitsi.org <mailto:dev@jitsi.org>
    >> Unsubscribe instructions and other list options:
    >> http://lists.jitsi.org/mailman/listinfo/dev

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#16

Hey Danny,

There is this bug with the formatting, and it is really annoying. Whenever
someone writes "for" or any other word that starts with "fo" it recognizes
it as my nickname, it even recognizes the nickname if it is not surrounded
by whitespace/punctuation and is in the middle of another word (screenshots
attached). Do you think you could fix that ?

Regards,
fo

···

On Thu, Sep 18, 2014 at 11:51 PM, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Hi Emil,

On 09/18/2014 08:14 AM, Emil Ivov wrote:
>
> Awesome! Thanks Danny! Will do!
>
> In the mean time, have you tried clicking the account checkbox
> multiple times in a row? I noticed something else there as well: chat
> rooms are being duplicated every time you do that. Now I am wondering
> if this is exclusive to IRC though.
>
I think this is exclusive to IRC. I adopted the original implementation
of the IRC accregwiz almost completely unchanged. This implementation
"modifies" an account by first removing it and then adding the modified
account again. This is most likely the cause of the duplication of IRC
channels.

As for the IRC connection itself. It seems that quickly
enabling/disabling IRC seems to be too fast to properly dispose of the
irc-api instance.

> I also get the duplicated account fairly often too. I'll see if I can
> get you more detail (did I already send you an exception stack trace
btw?)
>
I haven't received the exception trace yet, I believe. Also, quickly
enabling-disabling the account duplicated chat rooms, but it didn't
duplicate the account in the Options -> Accounts list, so repro recipe
is welcome.

> --sent from my mobile
>
Sent from my PC.

> On 17 Sep 2014 9:36 PM, "Danny van Heumen" <danny@dannyvanheumen.nl > > <mailto:danny@dannyvanheumen.nl>> wrote:
>
> Hi Emil,
>
> I've fixed the issue with right-click-join not working. It was due to
> some inconsistent UI behaviour.
>
> Let me know if you have another clue for your issue with 2 IRC
> connection instances. I haven't encountered it before, so without
> additional info I'm kinda dead in the water.
>
> Kind regards,
> Danny
>
>
> On 09/15/2014 08:22 PM, Emil Ivov wrote:
> > Hey Danny,
> >
> > On Mon, Sep 15, 2014 at 7:52 PM, Danny van Heumen > > > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>> wrote:
> >> Hi Emil,
> >>
> >> On 09/14/2014 11:37 PM, Emil Ivov wrote:
> >>> Hey Danny,
> >>>
> >>> I know a few people were on vacation (or in hospital) last week
so
> >>> this hasn't really been tested that much. It's a rather
> substantial
> >>> change so let's not rush it ... especially if you don't have
> the time
> >>> to worry about it.
> >>>
> >> I agree that we shouldn't rush it. But, I think people might be
> >> overestimating the amount of changes I've made. For example, the
> >> "replacers" are 1:1 the same code. (just moved to the "replacers"
> >> package and now implementing the Replacer interface) And I've
> made some
> >> things explicit such as calling the message HTML after it has been
> >> formatted.
> >>
> >> I believe that the way I find plain text in between HTML tags
> is the
> >> biggest change. (Not to excuse anything, just to point out where
> >> weaknesses might be ... ) Because of this, we may be processing
> slightly
> >> more content than previously, though I haven't noticed it in
> daily use.
> > Damencho, Yana, could you please have a look when possible?
> >
> >>> On a side note I have noticed that unregistering an IRC
> account from
> >>> the accounts panel and then registering it again seems to
> leave you
> >>> with two instances. Have you seen this?
> >>>
> >> Hmm... no, not that I can recall. Do you mean 2 instances of
> >> connections, or something visually in the UI?
> > Yes I see it appearing twice in the status combo box on top of the
> > search field. I am now seeing that I can't reproduce this reliably
> > though ... maybe it only happens after a standby? I'll keep
> observing.
> >
> >> In any case I'll play around with registering-unregistering a
> bit to see
> >> what I can find.
> >>
> >>> Also, right clicking on a channel and selecting "join" seems
> to often
> >>> fail for me whe double clicking the channel usually works.
> Does this
> >>> sound familiar?
> >>>
> >> Actually, I don't have a clue. I would expect the same code to
> be called
> >> here. Again, putting it on my TODO list.
> > This is what I see when right clicking:
> >
> > 20:12:58.557 INFO: [1160]
> > impl.protocol.irc.ChatRoomIrcImpl.setUserNickname().687 Setting
> a nick
> > name for an individual chat room is not supported for IRC.
> > 20:12:58.557 SEVERE: [1160]
> > com.ircclouds.irc.api.IRCApiImpl.executeAsync() Error executing
> > command
> > java.nio.channels.ClosedChannelException
> > at
>
sun.nio.ch.SocketChannelImpl.ensureReadOpen(SocketChannelImpl.java:122)
> > at
sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:165)
> > at
>
com.ircclouds.irc.api.comms.SSLSocketChannelConnection.tryReadAndUnwrap(SSLSocketChannelConnection.java:146)
> > at
>
com.ircclouds.irc.api.comms.SSLSocketChannelConnection.processHandshake(SSLSocketChannelConnection.java:123)
> > at
>
com.ircclouds.irc.api.comms.SSLSocketChannelConnection.doAnyPendingHandshake(SSLSocketChannelConnection.java:106)
> > at
>
com.ircclouds.irc.api.comms.SSLSocketChannelConnection.write(SSLSocketChannelConnection.java:67)
> > at
>
com.ircclouds.irc.api.AbstractCommandServerImpl.execute(AbstractCommandServerImpl.java:19)
> > at
> com.ircclouds.irc.api.IRCApiImpl.executeAsync(IRCApiImpl.java:593)
> > at
> com.ircclouds.irc.api.IRCApiImpl.joinChannel(IRCApiImpl.java:176)
> > at
>
net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:639)
> > at
>
net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:581)
> > at
>
net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.join(ChatRoomIrcImpl.java:323)
> > at
>
net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.joinAs(ChatRoomIrcImpl.java:356)
> > at
>
net.java.sip.communicator.impl.muc.MUCServiceImpl$JoinChatRoomTask.run(MUCServiceImpl.java:680)
> >
> > It might be a consequence of a different sequence of method calls
in
> > one case and in the other ... have no idea.
> >
> > Emil
> >
> >>> --sent from my mobile
> >>>
> >>> On 14 Sep 2014 9:45 PM, "Danny van Heumen" > > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl> > > >>> <mailto:danny@dannyvanheumen.nl > > <mailto:danny@dannyvanheumen.nl>>> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> So, has anyone had any problems while testing the new
> formatting code?
> >>>
> >>> I'd like to merge this shortly if possible, since
> otherwise it'll keep
> >>> dragging on. I haven't heard of anyone having issues, so
> far, and I
> >>> haven't noticed anything myself.
> >>>
> >>> Kind regards,
> >>> Danny
> >>>
> >>>
> >>> On 08/28/2014 10:28 PM, Danny van Heumen wrote:
> >>> > Hi all,
> >>> >
> >>> > I am planning to merge a modified implementation of the
> message
> >>> > formatting code that processes message that are about to be
> >>> displayed in
> >>> > the chat conversation window. This code improves on the
> >>> following aspects:
> >>> >
> >>> > 1. A different approach to handling (mixed) plain text
> and html
> >>> > messages. I process the plain text message once, strictly
> >>> leveraging the
> >>> > fact that the code knows exactly when text is plain text
> and when it
> >>> > gets turned into HTML (i.e. at least partially formatted
for
> >>> displaying
> >>> > already).
> >>> >
> >>> > 2. Not using <plaintext> tags anymore, since these
> cancel any active
> >>> > formatting, such as light-grey from system messages,
> headings
> >>> and such.
> >>> >
> >>> > 3. Strict HTML escaping for any text that should be
> displayed as is,
> >>> > this includes names of chat rooms, members and subjects.
> This is
> >>> > important since IRC channel names allow for almost any
> >>> character, so you
> >>> > can create a small HTML document as a chat room name,
> and we'd
> >>> like to
> >>> > prevent HTML injection.
> >>> >
> >>> > 4. Now that <plaintext> tags are gone, I've taken a
> different
> >>> approach
> >>> > to processing messages based on the plain text parts of
> the message:
> >>> > this approach searches for text in between the HTML tags
for
> >>> processing
> >>> > and escapes it automatically such that you can process
> based on the
> >>> > original content, instead of the HTML-escaped content.
> >>> >
> >>> > 5. Separate implementations, based on a public interface
> for the
> >>> > preprocessing steps that are executed on all incoming
> messages.
> >>> There is
> >>> > an interface called 'Replacer' for which a number of
> implementations
> >>> > exist that were previously available as individual
> methods. (A
> >>> separate
> >>> > package is created for these implementations.)
> >>> >
> >>> > 6. Fixed processing URL's in HTML text. (This previously
> only
> >>> worked for
> >>> > discovering hyperlinks in plain text message.)
> >>> >
> >>> > 7. Fixed ordering of processing keywords vs. hyperlinks:
> >>> previously if a
> >>> > keyword was highlighted, it would break the URL and the URL
> >>> wouldn't be
> >>> > recognized as such any more.
> >>> >
> >>> > 8. And finally, I've improved to regexp that searches
> for plain text
> >>> > content to recognize both tags (by <> brackets) and
> attribute
> >>> values by
> >>> > quotes (") such that we can quite reliably distinguish
parts
> >>> from HTML
> >>> > tags from actual text content.
> >>> >
> >>> > I plan to push these changes by tomorrow evening if
> there are no
> >>> > objections. I'd like to give you all a chance to respond
> beforehand,
> >>> > because this touches some quite significant code. If I
> need to
> >>> wait to
> >>> > do some more testing, I'm also fine with that.
> >>> >
> >>> > You can find the code at
> >>> >
> https://github.com/cobratbq/jitsi/commits/fix-message-formatting
> >>> > Any feedback is welcome!
> >>> >
> >>> > Kind regards,
> >>> > Danny
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > dev mailing list
> >>> > dev@jitsi.org <mailto:dev@jitsi.org>
> <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
> >>> > Unsubscribe instructions and other list options:
> >>> > http://lists.jitsi.org/mailman/listinfo/dev
> >>> >
> >>> >
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> dev mailing list
> >>> dev@jitsi.org <mailto:dev@jitsi.org> <mailto:dev@jitsi.org
> <mailto:dev@jitsi.org>>
> >>> Unsubscribe instructions and other list options:
> >>> http://lists.jitsi.org/mailman/listinfo/dev
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> dev mailing list
> >>> dev@jitsi.org <mailto:dev@jitsi.org>
> >>> Unsubscribe instructions and other list options:
> >>> http://lists.jitsi.org/mailman/listinfo/dev
> >>
> >>
> >> _______________________________________________
> >> dev mailing list
> >> dev@jitsi.org <mailto:dev@jitsi.org>
> >> Unsubscribe instructions and other list options:
> >> http://lists.jitsi.org/mailman/listinfo/dev
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org <mailto:dev@jitsi.org>
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#17

This doesn't seem to be an IRC thing though.

···

On Mon, Oct 20, 2014 at 4:36 PM, Svetlana Velichkova <fo@bluejimp.com> wrote:

Hey Danny,

There is this bug with the formatting, and it is really annoying. Whenever
someone writes "for" or any other word that starts with "fo" it recognizes
it as my nickname, it even recognizes the nickname if it is not surrounded
by whitespace/punctuation and is in the middle of another word (screenshots
attached). Do you think you could fix that ?

Regards,
fo

On Thu, Sep 18, 2014 at 11:51 PM, Danny van Heumen <danny@dannyvanheumen.nl> > wrote:

Hi Emil,

On 09/18/2014 08:14 AM, Emil Ivov wrote:
>
> Awesome! Thanks Danny! Will do!
>
> In the mean time, have you tried clicking the account checkbox
> multiple times in a row? I noticed something else there as well: chat
> rooms are being duplicated every time you do that. Now I am wondering
> if this is exclusive to IRC though.
>
I think this is exclusive to IRC. I adopted the original implementation
of the IRC accregwiz almost completely unchanged. This implementation
"modifies" an account by first removing it and then adding the modified
account again. This is most likely the cause of the duplication of IRC
channels.

As for the IRC connection itself. It seems that quickly
enabling/disabling IRC seems to be too fast to properly dispose of the
irc-api instance.

> I also get the duplicated account fairly often too. I'll see if I can
> get you more detail (did I already send you an exception stack trace
> btw?)
>
I haven't received the exception trace yet, I believe. Also, quickly
enabling-disabling the account duplicated chat rooms, but it didn't
duplicate the account in the Options -> Accounts list, so repro recipe
is welcome.

> --sent from my mobile
>
Sent from my PC.

> On 17 Sep 2014 9:36 PM, "Danny van Heumen" <danny@dannyvanheumen.nl >> > <mailto:danny@dannyvanheumen.nl>> wrote:
>
> Hi Emil,
>
> I've fixed the issue with right-click-join not working. It was due
> to
> some inconsistent UI behaviour.
>
> Let me know if you have another clue for your issue with 2 IRC
> connection instances. I haven't encountered it before, so without
> additional info I'm kinda dead in the water.
>
> Kind regards,
> Danny
>
>
> On 09/15/2014 08:22 PM, Emil Ivov wrote:
> > Hey Danny,
> >
> > On Mon, Sep 15, 2014 at 7:52 PM, Danny van Heumen >> > > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>> wrote:
> >> Hi Emil,
> >>
> >> On 09/14/2014 11:37 PM, Emil Ivov wrote:
> >>> Hey Danny,
> >>>
> >>> I know a few people were on vacation (or in hospital) last week
> so
> >>> this hasn't really been tested that much. It's a rather
> substantial
> >>> change so let's not rush it ... especially if you don't have
> the time
> >>> to worry about it.
> >>>
> >> I agree that we shouldn't rush it. But, I think people might be
> >> overestimating the amount of changes I've made. For example, the
> >> "replacers" are 1:1 the same code. (just moved to the "replacers"
> >> package and now implementing the Replacer interface) And I've
> made some
> >> things explicit such as calling the message HTML after it has
> been
> >> formatted.
> >>
> >> I believe that the way I find plain text in between HTML tags
> is the
> >> biggest change. (Not to excuse anything, just to point out where
> >> weaknesses might be ... ) Because of this, we may be processing
> slightly
> >> more content than previously, though I haven't noticed it in
> daily use.
> > Damencho, Yana, could you please have a look when possible?
> >
> >>> On a side note I have noticed that unregistering an IRC
> account from
> >>> the accounts panel and then registering it again seems to
> leave you
> >>> with two instances. Have you seen this?
> >>>
> >> Hmm... no, not that I can recall. Do you mean 2 instances of
> >> connections, or something visually in the UI?
> > Yes I see it appearing twice in the status combo box on top of the
> > search field. I am now seeing that I can't reproduce this reliably
> > though ... maybe it only happens after a standby? I'll keep
> observing.
> >
> >> In any case I'll play around with registering-unregistering a
> bit to see
> >> what I can find.
> >>
> >>> Also, right clicking on a channel and selecting "join" seems
> to often
> >>> fail for me whe double clicking the channel usually works.
> Does this
> >>> sound familiar?
> >>>
> >> Actually, I don't have a clue. I would expect the same code to
> be called
> >> here. Again, putting it on my TODO list.
> > This is what I see when right clicking:
> >
> > 20:12:58.557 INFO: [1160]
> > impl.protocol.irc.ChatRoomIrcImpl.setUserNickname().687 Setting
> a nick
> > name for an individual chat room is not supported for IRC.
> > 20:12:58.557 SEVERE: [1160]
> > com.ircclouds.irc.api.IRCApiImpl.executeAsync() Error executing
> > command
> > java.nio.channels.ClosedChannelException
> > at
>
> sun.nio.ch.SocketChannelImpl.ensureReadOpen(SocketChannelImpl.java:122)
> > at
> sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:165)
> > at
>
> com.ircclouds.irc.api.comms.SSLSocketChannelConnection.tryReadAndUnwrap(SSLSocketChannelConnection.java:146)
> > at
>
> com.ircclouds.irc.api.comms.SSLSocketChannelConnection.processHandshake(SSLSocketChannelConnection.java:123)
> > at
>
> com.ircclouds.irc.api.comms.SSLSocketChannelConnection.doAnyPendingHandshake(SSLSocketChannelConnection.java:106)
> > at
>
> com.ircclouds.irc.api.comms.SSLSocketChannelConnection.write(SSLSocketChannelConnection.java:67)
> > at
>
> com.ircclouds.irc.api.AbstractCommandServerImpl.execute(AbstractCommandServerImpl.java:19)
> > at
> com.ircclouds.irc.api.IRCApiImpl.executeAsync(IRCApiImpl.java:593)
> > at
> com.ircclouds.irc.api.IRCApiImpl.joinChannel(IRCApiImpl.java:176)
> > at
>
> net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:639)
> > at
>
> net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:581)
> > at
>
> net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.join(ChatRoomIrcImpl.java:323)
> > at
>
> net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.joinAs(ChatRoomIrcImpl.java:356)
> > at
>
> net.java.sip.communicator.impl.muc.MUCServiceImpl$JoinChatRoomTask.run(MUCServiceImpl.java:680)
> >
> > It might be a consequence of a different sequence of method calls
> in
> > one case and in the other ... have no idea.
> >
> > Emil
> >
> >>> --sent from my mobile
> >>>
> >>> On 14 Sep 2014 9:45 PM, "Danny van Heumen" >> > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl> >> > >>> <mailto:danny@dannyvanheumen.nl >> > <mailto:danny@dannyvanheumen.nl>>> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> So, has anyone had any problems while testing the new
> formatting code?
> >>>
> >>> I'd like to merge this shortly if possible, since
> otherwise it'll keep
> >>> dragging on. I haven't heard of anyone having issues, so
> far, and I
> >>> haven't noticed anything myself.
> >>>
> >>> Kind regards,
> >>> Danny
> >>>
> >>>
> >>> On 08/28/2014 10:28 PM, Danny van Heumen wrote:
> >>> > Hi all,
> >>> >
> >>> > I am planning to merge a modified implementation of the
> message
> >>> > formatting code that processes message that are about to
> be
> >>> displayed in
> >>> > the chat conversation window. This code improves on the
> >>> following aspects:
> >>> >
> >>> > 1. A different approach to handling (mixed) plain text
> and html
> >>> > messages. I process the plain text message once, strictly
> >>> leveraging the
> >>> > fact that the code knows exactly when text is plain text
> and when it
> >>> > gets turned into HTML (i.e. at least partially formatted
> for
> >>> displaying
> >>> > already).
> >>> >
> >>> > 2. Not using <plaintext> tags anymore, since these
> cancel any active
> >>> > formatting, such as light-grey from system messages,
> headings
> >>> and such.
> >>> >
> >>> > 3. Strict HTML escaping for any text that should be
> displayed as is,
> >>> > this includes names of chat rooms, members and subjects.
> This is
> >>> > important since IRC channel names allow for almost any
> >>> character, so you
> >>> > can create a small HTML document as a chat room name,
> and we'd
> >>> like to
> >>> > prevent HTML injection.
> >>> >
> >>> > 4. Now that <plaintext> tags are gone, I've taken a
> different
> >>> approach
> >>> > to processing messages based on the plain text parts of
> the message:
> >>> > this approach searches for text in between the HTML tags
> for
> >>> processing
> >>> > and escapes it automatically such that you can process
> based on the
> >>> > original content, instead of the HTML-escaped content.
> >>> >
> >>> > 5. Separate implementations, based on a public interface
> for the
> >>> > preprocessing steps that are executed on all incoming
> messages.
> >>> There is
> >>> > an interface called 'Replacer' for which a number of
> implementations
> >>> > exist that were previously available as individual
> methods. (A
> >>> separate
> >>> > package is created for these implementations.)
> >>> >
> >>> > 6. Fixed processing URL's in HTML text. (This previously
> only
> >>> worked for
> >>> > discovering hyperlinks in plain text message.)
> >>> >
> >>> > 7. Fixed ordering of processing keywords vs. hyperlinks:
> >>> previously if a
> >>> > keyword was highlighted, it would break the URL and the
> URL
> >>> wouldn't be
> >>> > recognized as such any more.
> >>> >
> >>> > 8. And finally, I've improved to regexp that searches
> for plain text
> >>> > content to recognize both tags (by <> brackets) and
> attribute
> >>> values by
> >>> > quotes (") such that we can quite reliably distinguish
> parts
> >>> from HTML
> >>> > tags from actual text content.
> >>> >
> >>> > I plan to push these changes by tomorrow evening if
> there are no
> >>> > objections. I'd like to give you all a chance to respond
> beforehand,
> >>> > because this touches some quite significant code. If I
> need to
> >>> wait to
> >>> > do some more testing, I'm also fine with that.
> >>> >
> >>> > You can find the code at
> >>> >
> https://github.com/cobratbq/jitsi/commits/fix-message-formatting
> >>> > Any feedback is welcome!
> >>> >
> >>> > Kind regards,
> >>> > Danny
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > dev mailing list
> >>> > dev@jitsi.org <mailto:dev@jitsi.org>
> <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
> >>> > Unsubscribe instructions and other list options:
> >>> > http://lists.jitsi.org/mailman/listinfo/dev
> >>> >
> >>> >
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> dev mailing list
> >>> dev@jitsi.org <mailto:dev@jitsi.org> <mailto:dev@jitsi.org
> <mailto:dev@jitsi.org>>
> >>> Unsubscribe instructions and other list options:
> >>> http://lists.jitsi.org/mailman/listinfo/dev
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> dev mailing list
> >>> dev@jitsi.org <mailto:dev@jitsi.org>
> >>> Unsubscribe instructions and other list options:
> >>> http://lists.jitsi.org/mailman/listinfo/dev
> >>
> >>
> >> _______________________________________________
> >> dev mailing list
> >> dev@jitsi.org <mailto:dev@jitsi.org>
> >> Unsubscribe instructions and other list options:
> >> http://lists.jitsi.org/mailman/listinfo/dev
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org <mailto:dev@jitsi.org>
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#18

Sorry Danny,
I just realized my message might have sounded a bit harsh, I didn't mean to
imply that it was your bug. I was just talking about it with Damencho
offline and we remembered that there were some changes you made recently
and thought you had the best chance of knowing what the problem was. Do you
think it would be easy to fix?
We don't know if it was working before merging your changes from the
fix-message-formatting branch but we are going to check it.

Regards,
fo

···

On Mon, Oct 20, 2014 at 5:45 PM, Emil Ivov <emcho@jitsi.org> wrote:

This doesn't seem to be an IRC thing though.

On Mon, Oct 20, 2014 at 4:36 PM, Svetlana Velichkova <fo@bluejimp.com> > wrote:
> Hey Danny,
>
> There is this bug with the formatting, and it is really annoying.
Whenever
> someone writes "for" or any other word that starts with "fo" it
recognizes
> it as my nickname, it even recognizes the nickname if it is not
surrounded
> by whitespace/punctuation and is in the middle of another word
(screenshots
> attached). Do you think you could fix that ?
>
> Regards,
> fo
>
>
> On Thu, Sep 18, 2014 at 11:51 PM, Danny van Heumen < > danny@dannyvanheumen.nl> > > wrote:
>>
>> Hi Emil,
>>
>>
>> On 09/18/2014 08:14 AM, Emil Ivov wrote:
>> >
>> > Awesome! Thanks Danny! Will do!
>> >
>> > In the mean time, have you tried clicking the account checkbox
>> > multiple times in a row? I noticed something else there as well: chat
>> > rooms are being duplicated every time you do that. Now I am wondering
>> > if this is exclusive to IRC though.
>> >
>> I think this is exclusive to IRC. I adopted the original implementation
>> of the IRC accregwiz almost completely unchanged. This implementation
>> "modifies" an account by first removing it and then adding the modified
>> account again. This is most likely the cause of the duplication of IRC
>> channels.
>>
>> As for the IRC connection itself. It seems that quickly
>> enabling/disabling IRC seems to be too fast to properly dispose of the
>> irc-api instance.
>>
>> > I also get the duplicated account fairly often too. I'll see if I can
>> > get you more detail (did I already send you an exception stack trace
>> > btw?)
>> >
>> I haven't received the exception trace yet, I believe. Also, quickly
>> enabling-disabling the account duplicated chat rooms, but it didn't
>> duplicate the account in the Options -> Accounts list, so repro recipe
>> is welcome.
>>
>>
>> > --sent from my mobile
>> >
>> Sent from my PC.
>>
>>
>> > On 17 Sep 2014 9:36 PM, "Danny van Heumen" <danny@dannyvanheumen.nl > >> > <mailto:danny@dannyvanheumen.nl>> wrote:
>> >
>> > Hi Emil,
>> >
>> > I've fixed the issue with right-click-join not working. It was due
>> > to
>> > some inconsistent UI behaviour.
>> >
>> > Let me know if you have another clue for your issue with 2 IRC
>> > connection instances. I haven't encountered it before, so without
>> > additional info I'm kinda dead in the water.
>> >
>> > Kind regards,
>> > Danny
>> >
>> >
>> > On 09/15/2014 08:22 PM, Emil Ivov wrote:
>> > > Hey Danny,
>> > >
>> > > On Mon, Sep 15, 2014 at 7:52 PM, Danny van Heumen > >> > > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>> > wrote:
>> > >> Hi Emil,
>> > >>
>> > >> On 09/14/2014 11:37 PM, Emil Ivov wrote:
>> > >>> Hey Danny,
>> > >>>
>> > >>> I know a few people were on vacation (or in hospital) last
week
>> > so
>> > >>> this hasn't really been tested that much. It's a rather
>> > substantial
>> > >>> change so let's not rush it ... especially if you don't have
>> > the time
>> > >>> to worry about it.
>> > >>>
>> > >> I agree that we shouldn't rush it. But, I think people might be
>> > >> overestimating the amount of changes I've made. For example,
the
>> > >> "replacers" are 1:1 the same code. (just moved to the
"replacers"
>> > >> package and now implementing the Replacer interface) And I've
>> > made some
>> > >> things explicit such as calling the message HTML after it has
>> > been
>> > >> formatted.
>> > >>
>> > >> I believe that the way I find plain text in between HTML tags
>> > is the
>> > >> biggest change. (Not to excuse anything, just to point out
where
>> > >> weaknesses might be ... ) Because of this, we may be processing
>> > slightly
>> > >> more content than previously, though I haven't noticed it in
>> > daily use.
>> > > Damencho, Yana, could you please have a look when possible?
>> > >
>> > >>> On a side note I have noticed that unregistering an IRC
>> > account from
>> > >>> the accounts panel and then registering it again seems to
>> > leave you
>> > >>> with two instances. Have you seen this?
>> > >>>
>> > >> Hmm... no, not that I can recall. Do you mean 2 instances of
>> > >> connections, or something visually in the UI?
>> > > Yes I see it appearing twice in the status combo box on top of
the
>> > > search field. I am now seeing that I can't reproduce this
reliably
>> > > though ... maybe it only happens after a standby? I'll keep
>> > observing.
>> > >
>> > >> In any case I'll play around with registering-unregistering a
>> > bit to see
>> > >> what I can find.
>> > >>
>> > >>> Also, right clicking on a channel and selecting "join" seems
>> > to often
>> > >>> fail for me whe double clicking the channel usually works.
>> > Does this
>> > >>> sound familiar?
>> > >>>
>> > >> Actually, I don't have a clue. I would expect the same code to
>> > be called
>> > >> here. Again, putting it on my TODO list.
>> > > This is what I see when right clicking:
>> > >
>> > > 20:12:58.557 INFO: [1160]
>> > > impl.protocol.irc.ChatRoomIrcImpl.setUserNickname().687 Setting
>> > a nick
>> > > name for an individual chat room is not supported for IRC.
>> > > 20:12:58.557 SEVERE: [1160]
>> > > com.ircclouds.irc.api.IRCApiImpl.executeAsync() Error executing
>> > > command
>> > > java.nio.channels.ClosedChannelException
>> > > at
>> >
>> >
sun.nio.ch.SocketChannelImpl.ensureReadOpen(SocketChannelImpl.java:122)
>> > > at
>> > sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:165)
>> > > at
>> >
>> >
com.ircclouds.irc.api.comms.SSLSocketChannelConnection.tryReadAndUnwrap(SSLSocketChannelConnection.java:146)
>> > > at
>> >
>> >
com.ircclouds.irc.api.comms.SSLSocketChannelConnection.processHandshake(SSLSocketChannelConnection.java:123)
>> > > at
>> >
>> >
com.ircclouds.irc.api.comms.SSLSocketChannelConnection.doAnyPendingHandshake(SSLSocketChannelConnection.java:106)
>> > > at
>> >
>> >
com.ircclouds.irc.api.comms.SSLSocketChannelConnection.write(SSLSocketChannelConnection.java:67)
>> > > at
>> >
>> >
com.ircclouds.irc.api.AbstractCommandServerImpl.execute(AbstractCommandServerImpl.java:19)
>> > > at
>> > com.ircclouds.irc.api.IRCApiImpl.executeAsync(IRCApiImpl.java:593)
>> > > at
>> > com.ircclouds.irc.api.IRCApiImpl.joinChannel(IRCApiImpl.java:176)
>> > > at
>> >
>> >
net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:639)
>> > > at
>> >
>> >
net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:581)
>> > > at
>> >
>> >
net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.join(ChatRoomIrcImpl.java:323)
>> > > at
>> >
>> >
net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.joinAs(ChatRoomIrcImpl.java:356)
>> > > at
>> >
>> >
net.java.sip.communicator.impl.muc.MUCServiceImpl$JoinChatRoomTask.run(MUCServiceImpl.java:680)
>> > >
>> > > It might be a consequence of a different sequence of method
calls
>> > in
>> > > one case and in the other ... have no idea.
>> > >
>> > > Emil
>> > >
>> > >>> --sent from my mobile
>> > >>>
>> > >>> On 14 Sep 2014 9:45 PM, "Danny van Heumen" > >> > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl> > >> > >>> <mailto:danny@dannyvanheumen.nl > >> > <mailto:danny@dannyvanheumen.nl>>> wrote:
>> > >>>
>> > >>> Hi all,
>> > >>>
>> > >>> So, has anyone had any problems while testing the new
>> > formatting code?
>> > >>>
>> > >>> I'd like to merge this shortly if possible, since
>> > otherwise it'll keep
>> > >>> dragging on. I haven't heard of anyone having issues, so
>> > far, and I
>> > >>> haven't noticed anything myself.
>> > >>>
>> > >>> Kind regards,
>> > >>> Danny
>> > >>>
>> > >>>
>> > >>> On 08/28/2014 10:28 PM, Danny van Heumen wrote:
>> > >>> > Hi all,
>> > >>> >
>> > >>> > I am planning to merge a modified implementation of the
>> > message
>> > >>> > formatting code that processes message that are about to
>> > be
>> > >>> displayed in
>> > >>> > the chat conversation window. This code improves on the
>> > >>> following aspects:
>> > >>> >
>> > >>> > 1. A different approach to handling (mixed) plain text
>> > and html
>> > >>> > messages. I process the plain text message once,
strictly
>> > >>> leveraging the
>> > >>> > fact that the code knows exactly when text is plain text
>> > and when it
>> > >>> > gets turned into HTML (i.e. at least partially formatted
>> > for
>> > >>> displaying
>> > >>> > already).
>> > >>> >
>> > >>> > 2. Not using <plaintext> tags anymore, since these
>> > cancel any active
>> > >>> > formatting, such as light-grey from system messages,
>> > headings
>> > >>> and such.
>> > >>> >
>> > >>> > 3. Strict HTML escaping for any text that should be
>> > displayed as is,
>> > >>> > this includes names of chat rooms, members and subjects.
>> > This is
>> > >>> > important since IRC channel names allow for almost any
>> > >>> character, so you
>> > >>> > can create a small HTML document as a chat room name,
>> > and we'd
>> > >>> like to
>> > >>> > prevent HTML injection.
>> > >>> >
>> > >>> > 4. Now that <plaintext> tags are gone, I've taken a
>> > different
>> > >>> approach
>> > >>> > to processing messages based on the plain text parts of
>> > the message:
>> > >>> > this approach searches for text in between the HTML tags
>> > for
>> > >>> processing
>> > >>> > and escapes it automatically such that you can process
>> > based on the
>> > >>> > original content, instead of the HTML-escaped content.
>> > >>> >
>> > >>> > 5. Separate implementations, based on a public interface
>> > for the
>> > >>> > preprocessing steps that are executed on all incoming
>> > messages.
>> > >>> There is
>> > >>> > an interface called 'Replacer' for which a number of
>> > implementations
>> > >>> > exist that were previously available as individual
>> > methods. (A
>> > >>> separate
>> > >>> > package is created for these implementations.)
>> > >>> >
>> > >>> > 6. Fixed processing URL's in HTML text. (This previously
>> > only
>> > >>> worked for
>> > >>> > discovering hyperlinks in plain text message.)
>> > >>> >
>> > >>> > 7. Fixed ordering of processing keywords vs. hyperlinks:
>> > >>> previously if a
>> > >>> > keyword was highlighted, it would break the URL and the
>> > URL
>> > >>> wouldn't be
>> > >>> > recognized as such any more.
>> > >>> >
>> > >>> > 8. And finally, I've improved to regexp that searches
>> > for plain text
>> > >>> > content to recognize both tags (by <> brackets) and
>> > attribute
>> > >>> values by
>> > >>> > quotes (") such that we can quite reliably distinguish
>> > parts
>> > >>> from HTML
>> > >>> > tags from actual text content.
>> > >>> >
>> > >>> > I plan to push these changes by tomorrow evening if
>> > there are no
>> > >>> > objections. I'd like to give you all a chance to respond
>> > beforehand,
>> > >>> > because this touches some quite significant code. If I
>> > need to
>> > >>> wait to
>> > >>> > do some more testing, I'm also fine with that.
>> > >>> >
>> > >>> > You can find the code at
>> > >>> >
>> > https://github.com/cobratbq/jitsi/commits/fix-message-formatting
>> > >>> > Any feedback is welcome!
>> > >>> >
>> > >>> > Kind regards,
>> > >>> > Danny
>> > >>> >
>> > >>> >
>> > >>> >
>> > >>> >
>> > >>> >
>> > >>> >
>> > >>> > _______________________________________________
>> > >>> > dev mailing list
>> > >>> > dev@jitsi.org <mailto:dev@jitsi.org>
>> > <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
>> > >>> > Unsubscribe instructions and other list options:
>> > >>> > http://lists.jitsi.org/mailman/listinfo/dev
>> > >>> >
>> > >>> >
>> > >>>
>> > >>>
>> > >>>
>> > >>> _______________________________________________
>> > >>> dev mailing list
>> > >>> dev@jitsi.org <mailto:dev@jitsi.org> <mailto:
dev@jitsi.org
>> > <mailto:dev@jitsi.org>>
>> > >>> Unsubscribe instructions and other list options:
>> > >>> http://lists.jitsi.org/mailman/listinfo/dev
>> > >>>
>> > >>>
>> > >>>
>> > >>> _______________________________________________
>> > >>> dev mailing list
>> > >>> dev@jitsi.org <mailto:dev@jitsi.org>
>> > >>> Unsubscribe instructions and other list options:
>> > >>> http://lists.jitsi.org/mailman/listinfo/dev
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> dev mailing list
>> > >> dev@jitsi.org <mailto:dev@jitsi.org>
>> > >> Unsubscribe instructions and other list options:
>> > >> http://lists.jitsi.org/mailman/listinfo/dev
>> >
>> >
>> > _______________________________________________
>> > dev mailing list
>> > dev@jitsi.org <mailto:dev@jitsi.org>
>> > Unsubscribe instructions and other list options:
>> > http://lists.jitsi.org/mailman/listinfo/dev
>> >
>> >
>> >
>> > _______________________________________________
>> > dev mailing list
>> > dev@jitsi.org
>> > Unsubscribe instructions and other list options:
>> > http://lists.jitsi.org/mailman/listinfo/dev
>>
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#19
···

Hey fo,

  I've cooked something up this evening. This should be fixed in nightly (as of 3c8b3127adfd8d94333e316b038e8b3033e3292b).

  Let me know if you find some special case that isn't correctly supported yet.

  Danny

  On 20-10-14 16:36, Svetlana Velichkova wrote:

Hey Danny,

      There is this bug with the formatting, and it is really annoying. Whenever someone writes "for" or any other word that starts with "fo" it recognizes it as my nickname, it even recognizes the nickname if it is not surrounded by whitespace/punctuation and is in the middle of another word (screenshots attached). Do you think you could fix that ?

Regards,

fo

      On Thu, Sep 18, 2014 at 11:51 PM, Danny van Heumen <danny@dannyvanheumen.nl>
      wrote:

Hi Emil,

          On 09/18/2014 08:14 AM, Emil Ivov wrote:

          >

          > Awesome! Thanks Danny! Will do!

          >

          > In the mean time,� have you tried clicking the account checkbox

          > multiple times in a row? I noticed something else there as well: chat

          > rooms are being duplicated every time you do that. Now I am wondering

          > if this is exclusive to IRC though.

          >

                    I think this is exclusive to IRC. I adopted the original implementation

        of the IRC accregwiz almost completely unchanged. This implementation

        "modifies" an account by first removing it and then adding the modified

        account again. This is most likely the cause of the duplication of IRC

        channels.



        As for the IRC connection itself. It seems that quickly

        enabling/disabling IRC seems to be too fast to properly dispose of the

        irc-api instance.



          > I also get the duplicated account fairly often too. I'll see if I can

          > get you more detail (did I already send you an exception stack trace btw?)

          >

                    I haven't received the exception trace yet, I believe. Also, quickly

        enabling-disabling the account duplicated chat rooms, but it didn't

        duplicate the account in the Options -> Accounts list, so repro recipe

        is welcome.





        > --sent from my mobile

        >

        Sent from my PC.





          > On 17 Sep 2014 9:36 PM, "Danny van Heumen" <danny@dannyvanheumen.nl

        > <mailto:danny@dannyvanheumen.nl              >> wrote:

          >

          >� � �Hi Emil,

          >

          >� � �I've fixed the issue with right-click-join not working. It was due to

          >� � �some inconsistent UI behaviour.

          >

          >� � �Let me know if you have another clue for your issue with 2 IRC

          >� � �connection instances. I haven't encountered it before, so without

          >� � �additional info I'm kinda dead in the water.

          >

          >� � �Kind regards,

          >� � �Danny

          >

          >

          >� � �On 09/15/2014 08:22 PM, Emil Ivov wrote:

          >� � �> Hey Danny,

          >� � �>

          >� � �> On Mon, Sep 15, 2014 at 7:52 PM, Danny van Heumen

� � �> <danny@dannyvanheumen.nl
<mailto:danny@dannyvanheumen.nl >> wrote:

            >� � �>> Hi Emil,

            >� � �>>

            >� � �>> On 09/14/2014 11:37 PM, Emil Ivov wrote:

            >� � �>>> Hey Danny,

            >� � �>>>

            >� � �>>> I know a few people were on vacation (or in hospital) last week so

            >� � �>>> this hasn't really been tested that much. It's a rather

            >� � �substantial

            >� � �>>> change so let's not rush it ... especially if you don't have

            >� � �the time

            >� � �>>> to worry about it.

            >� � �>>>

            >� � �>> I agree that we shouldn't rush it. But, I think people might be

            >� � �>> overestimating the amount of changes I've made. For example, the

            >� � �>> "replacers" are 1:1 the same code. (just moved to the "replacers"

            >� � �>> package and now implementing the Replacer interface) And I've

            >� � �made some

            >� � �>> things explicit such as calling the message HTML after it has been

            >� � �>> formatted.

            >� � �>>

            >� � �>> I believe that the way I find plain text in between HTML tags

            >� � �is the

            >� � �>> biggest change. (Not to excuse anything, just to point out where

            >� � �>> weaknesses might be ... ) Because of this, we may be processing

            >� � �slightly

            >� � �>> more content than previously, though I haven't noticed it in

            >� � �daily use.

            >� � �> Damencho, Yana, could you please have a look when possible?

            >� � �>

            >� � �>>> On a side note I have noticed that unregistering an IRC

            >� � �account from

            >� � �>>> the accounts panel and then registering it again seems to

            >� � �leave you

            >� � �>>> with two instances. Have you seen this?

            >� � �>>>

            >� � �>> Hmm... no, not that I can recall. Do you mean 2 instances of

            >� � �>> connections, or something visually in the UI?

            >� � �> Yes I see it appearing twice in the status combo box on top of the

            >� � �> search field. I am now seeing that I can't reproduce this reliably

            >� � �> though ... maybe it only happens after a standby? I'll keep

            >� � �observing.

            >� � �>

            >� � �>> In any case I'll play around with registering-unregistering a

            >� � �bit to see

            >� � �>> what I can find.

            >� � �>>

            >� � �>>> Also, right clicking on a channel and selecting "join" seems

            >� � �to often

            >� � �>>> fail for me whe double clicking the channel usually works.

            >� � �Does this

            >� � �>>> sound familiar?

            >� � �>>>

            >� � �>> Actually, I don't have a clue. I would expect the same code to

            >� � �be called

            >� � �>> here. Again, putting it on my TODO list.

            >� � �> This is what I see when right clicking:

            >� � �>

            >� � �> 20:12:58.557 INFO: [1160]

            >� � �> impl.protocol.irc.ChatRoomIrcImpl.setUserNickname().687 Setting

            >� � �a nick

            >� � �> name for an individual chat room is not supported for IRC.

            >� � �> 20:12:58.557 SEVERE: [1160]

            >� � �> com.ircclouds.irc.api.IRCApiImpl.executeAsync() Error executing

            >� � �> command

            >� � �> java.nio.channels.ClosedChannelException

            >� � �>� � �at

            >� � �sun.nio.ch.SocketChannelImpl.ensureReadOpen(SocketChannelImpl.java:122)

            >� � �>� � �at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:165)

            >� � �>� � �at

            >� � �com.ircclouds.irc.api.comms.SSLSocketChannelConnection.tryReadAndUnwrap(SSLSocketChannelConnection.java:146)

            >� � �>� � �at

            >� � �com.ircclouds.irc.api.comms.SSLSocketChannelConnection.processHandshake(SSLSocketChannelConnection.java:123)

            >� � �>� � �at

            >� � �com.ircclouds.irc.api.comms.SSLSocketChannelConnection.doAnyPendingHandshake(SSLSocketChannelConnection.java:106)

            >� � �>� � �at

            >� � �com.ircclouds.irc.api.comms.SSLSocketChannelConnection.write(SSLSocketChannelConnection.java:67)

            >� � �>� � �at

            >� � �com.ircclouds.irc.api.AbstractCommandServerImpl.execute(AbstractCommandServerImpl.java:19)

            >� � �>� � �at

            >� � �com.ircclouds.irc.api.IRCApiImpl.executeAsync(IRCApiImpl.java:593)

            >� � �>� � �at

            >� � �com.ircclouds.irc.api.IRCApiImpl.joinChannel(IRCApiImpl.java:176)

            >� � �>� � �at

            >� � �net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:639)

            >� � �>� � �at

            >� � �net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:581)

            >� � �>� � �at

            >� � �net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.join(ChatRoomIrcImpl.java:323)

            >� � �>� � �at

            >� � �net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.joinAs(ChatRoomIrcImpl.java:356)

            >� � �>� � �at

            >� � �net.java.sip.communicator.impl.muc.MUCServiceImpl$JoinChatRoomTask.run(MUCServiceImpl.java:680)

            >� � �>

            >� � �> It might be a consequence of a different sequence of method calls in

            >� � �> one case and in the other ... have no idea.

            >� � �>

            >� � �> Emil

            >� � �>

            >� � �>>> --sent from my mobile

            >� � �>>>

            >� � �>>> On 14 Sep 2014 9:45 PM, "Danny van Heumen"

            >� � �<danny@dannyvanheumen.nl
            <mailto:danny@dannyvanheumen.nl>

� � �>>> <mailto:danny@dannyvanheumen.nl
� � �<mailto:danny@dannyvanheumen.nl >>> wrote:

            >� � �>>>

            >� � �>>>� � �Hi all,

            >� � �>>>

            >� � �>>>� � �So, has anyone had any problems while testing the new

            >� � �formatting code?

            >� � �>>>

            >� � �>>>� � �I'd like to merge this shortly if possible, since

            >� � �otherwise it'll keep

            >� � �>>>� � �dragging on. I haven't heard of anyone having issues, so

            >� � �far, and I

            >� � �>>>� � �haven't noticed anything myself.

            >� � �>>>

            >� � �>>>� � �Kind regards,

            >� � �>>>� � �Danny

            >� � �>>>

            >� � �>>>

            >� � �>>>� � �On 08/28/2014 10:28 PM, Danny van Heumen wrote:

            >� � �>>>� � �> Hi all,

            >� � �>>>� � �>

            >� � �>>>� � �> I am planning to merge a modified implementation of the

            >� � �message

            >� � �>>>� � �> formatting code that processes message that are about to be

            >� � �>>>� � �displayed in

            >� � �>>>� � �> the chat conversation window. This code improves on the

            >� � �>>>� � �following aspects:

            >� � �>>>� � �>

            >� � �>>>� � �> 1. A different approach to handling (mixed) plain text

            >� � �and html

            >� � �>>>� � �> messages. I process the plain text message once, strictly

            >� � �>>>� � �leveraging the

            >� � �>>>� � �> fact that the code knows exactly when text is plain text

            >� � �and when it

            >� � �>>>� � �> gets turned into HTML (i.e. at least partially formatted for

            >� � �>>>� � �displaying

            >� � �>>>� � �> already).

            >� � �>>>� � �>

            >� � �>>>� � �> 2. Not using <plaintext> tags anymore, since these

            >� � �cancel any active

            >� � �>>>� � �> formatting, such as light-grey from system messages,

            >� � �headings

            >� � �>>>� � �and such.

            >� � �>>>� � �>

            >� � �>>>� � �> 3. Strict HTML escaping for any text that should be

            >� � �displayed as is,

            >� � �>>>� � �> this includes names of chat rooms, members and subjects.

            >� � �This is

            >� � �>>>� � �> important since IRC channel names allow for almost any

            >� � �>>>� � �character, so you

            >� � �>>>� � �> can create a small HTML document as a chat room name,

            >� � �and we'd

            >� � �>>>� � �like to

            >� � �>>>� � �> prevent HTML injection.

            >� � �>>>� � �>

            >� � �>>>� � �> 4. Now that <plaintext> tags are gone, I've taken a

            >� � �different

            >� � �>>>� � �approach

            >� � �>>>� � �> to processing messages based on the plain text parts of

            >� � �the message:

            >� � �>>>� � �> this approach searches for text in between the HTML tags for

            >� � �>>>� � �processing

            >� � �>>>� � �> and escapes it automatically such that you can process

            >� � �based on the

            >� � �>>>� � �> original content, instead of the HTML-escaped content.

            >� � �>>>� � �>

            >� � �>>>� � �> 5. Separate implementations, based on a public interface

            >� � �for the

            >� � �>>>� � �> preprocessing steps that are executed on all incoming

            >� � �messages.

            >� � �>>>� � �There is

            >� � �>>>� � �> an interface called 'Replacer' for which a number of

            >� � �implementations

            >� � �>>>� � �> exist that were previously available as individual

            >� � �methods. (A

            >� � �>>>� � �separate

            >� � �>>>� � �> package is created for these implementations.)

            >� � �>>>� � �>

            >� � �>>>� � �> 6. Fixed processing URL's in HTML text. (This previously

            >� � �only

            >� � �>>>� � �worked for

            >� � �>>>� � �> discovering hyperlinks in plain text message.)

            >� � �>>>� � �>

            >� � �>>>� � �> 7. Fixed ordering of processing keywords vs. hyperlinks:

            >� � �>>>� � �previously if a

            >� � �>>>� � �> keyword was highlighted, it would break the URL and the URL

            >� � �>>>� � �wouldn't be

            >� � �>>>� � �> recognized as such any more.

            >� � �>>>� � �>

            >� � �>>>� � �> 8. And finally, I've improved to regexp that searches

            >� � �for plain text

            >� � �>>>� � �> content to recognize both tags (by <> brackets) and

            >� � �attribute

            >� � �>>>� � �values by

            >� � �>>>� � �> quotes (") such that we can quite reliably distinguish parts

            >� � �>>>� � �from HTML

            >� � �>>>� � �> tags from actual text content.

            >� � �>>>� � �>

            >� � �>>>� � �> I plan to push these changes by tomorrow evening if

            >� � �there are no

            >� � �>>>� � �> objections. I'd like to give you all a chance to respond

            >� � �beforehand,

            >� � �>>>� � �> because this touches some quite significant code. If I

            >� � �need to

            >� � �>>>� � �wait to

            >� � �>>>� � �> do some more testing, I'm also fine with that.

            >� � �>>>� � �>

            >� � �>>>� � �> You can find the code at

            >� � �>>>� � �>

            >� � �[https://github.com/cobratbq/jitsi/commits/fix-message-formatting](https://github.com/cobratbq/jitsi/commits/fix-message-formatting)

            >� � �>>>� � �> Any feedback is welcome!

            >� � �>>>� � �>

            >� � �>>>� � �> Kind regards,

            >� � �>>>� � �> Danny

            >� � �>>>� � �>

            >� � �>>>� � �>

            >� � �>>>� � �>

            >� � �>>>� � �>

            >� � �>>>� � �>

            >� � �>>>� � �>

            >� � �>>>� � �> _______________________________________________

            >� � �>>>� � �> dev mailing list

            >� � �>>>� � �> dev@jitsi.org
            <mailto:dev@jitsi.org>

� � �<mailto:dev@jitsi.org mailto:dev@jitsi.org>

                      >� � �>>>� � �> Unsubscribe instructions and other list options:

          >� � �>>>� � �> [http://lists.jitsi.org/mailman/listinfo/dev](http://lists.jitsi.org/mailman/listinfo/dev)

          >� � �>>>� � �>

          >� � �>>>� � �>

          >� � �>>>

          >� � �>>>

          >� � �>>>

          >� � �>>>� � �_______________________________________________

          >� � �>>>� � �dev mailing list

        >� � �>>>� � �dev@jitsi.org <mailto:dev@jitsi.org            > <mailto:dev@jitsi.org

� � �mailto:dev@jitsi.org>

            >� � �>>>� � �Unsubscribe instructions and other list options:

            >� � �>>>� � �[http://lists.jitsi.org/mailman/listinfo/dev](http://lists.jitsi.org/mailman/listinfo/dev)

            >� � �>>>

            >� � �>>>

            >� � �>>>

            >� � �>>> _______________________________________________

            >� � �>>> dev mailing list

            >� � �>>> dev@jitsi.org
            <mailto:dev@jitsi.org>

            >� � �>>> Unsubscribe instructions and other list options:

            >� � �>>> [http://lists.jitsi.org/mailman/listinfo/dev](http://lists.jitsi.org/mailman/listinfo/dev)

            >� � �>>

            >� � �>>

            >� � �>> _______________________________________________

            >� � �>> dev mailing list

            >� � �>> dev@jitsi.org
            <mailto:dev@jitsi.org>

            >� � �>> Unsubscribe instructions and other list options:

            >� � �>> [http://lists.jitsi.org/mailman/listinfo/dev](http://lists.jitsi.org/mailman/listinfo/dev)

            >

            >

            >� � �_______________________________________________

            >� � �dev mailing list

            >� � �dev@jitsi.org
            <mailto:dev@jitsi.org>

            >� � �Unsubscribe instructions and other list options:

            >� � �[http://lists.jitsi.org/mailman/listinfo/dev](http://lists.jitsi.org/mailman/listinfo/dev)

            >

            >

            >

            > _______________________________________________

            > dev mailing list

            > dev@jitsi.org

            > Unsubscribe instructions and other list options:

            > [http://lists.jitsi.org/mailman/listinfo/dev](http://lists.jitsi.org/mailman/listinfo/dev)







            _______________________________________________

            dev mailing list

            dev@jitsi.org

            Unsubscribe instructions and other list options:

            [http://lists.jitsi.org/mailman/listinfo/dev](http://lists.jitsi.org/mailman/listinfo/dev)

_______________________________________________ dev mailing list Unsubscribe instructions and other list options:

dev@jitsi.orghttp://lists.jitsi.org/mailman/listinfo/dev


#20

We ran some tests and this doesn't appear to be something new -- it happens with 818ace92b45ef157bf394eaa8e8a0efb5fccc777.

Regards,
Boris

···

On 20/10/14 18:03, Svetlana Velichkova wrote:

Sorry Danny,
I just realized my message might have sounded a bit harsh, I didn't mean
to imply that it was your bug. I was just talking about it with Damencho
offline and we remembered that there were some changes you made recently
and thought you had the best chance of knowing what the problem was. Do
you think it would be easy to fix?
We don't know if it was working before merging your changes from the
fix-message-formatting branch but we are going to check it.

Regards,
fo

On Mon, Oct 20, 2014 at 5:45 PM, Emil Ivov <emcho@jitsi.org > <mailto:emcho@jitsi.org>> wrote:

    This doesn't seem to be an IRC thing though.

    On Mon, Oct 20, 2014 at 4:36 PM, Svetlana Velichkova > <fo@bluejimp.com <mailto:fo@bluejimp.com>> wrote:
     > Hey Danny,
     >
     > There is this bug with the formatting, and it is really annoying.
    Whenever
     > someone writes "for" or any other word that starts with "fo" it
    recognizes
     > it as my nickname, it even recognizes the nickname if it is not
    surrounded
     > by whitespace/punctuation and is in the middle of another word
    (screenshots
     > attached). Do you think you could fix that ?
     >
     > Regards,
     > fo
     >
     > On Thu, Sep 18, 2014 at 11:51 PM, Danny van Heumen > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>> > > wrote:
     >>
     >> Hi Emil,
     >>
     >> On 09/18/2014 08:14 AM, Emil Ivov wrote:
     >> >
     >> > Awesome! Thanks Danny! Will do!
     >> >
     >> > In the mean time, have you tried clicking the account checkbox
     >> > multiple times in a row? I noticed something else there as
    well: chat
     >> > rooms are being duplicated every time you do that. Now I am
    wondering
     >> > if this is exclusive to IRC though.
     >> >
     >> I think this is exclusive to IRC. I adopted the original
    implementation
     >> of the IRC accregwiz almost completely unchanged. This
    implementation
     >> "modifies" an account by first removing it and then adding the
    modified
     >> account again. This is most likely the cause of the duplication
    of IRC
     >> channels.
     >>
     >> As for the IRC connection itself. It seems that quickly
     >> enabling/disabling IRC seems to be too fast to properly dispose
    of the
     >> irc-api instance.
     >>
     >> > I also get the duplicated account fairly often too. I'll see
    if I can
     >> > get you more detail (did I already send you an exception stack
    trace
     >> > btw?)
     >> >
     >> I haven't received the exception trace yet, I believe. Also, quickly
     >> enabling-disabling the account duplicated chat rooms, but it didn't
     >> duplicate the account in the Options -> Accounts list, so repro
    recipe
     >> is welcome.
     >>
     >> > --sent from my mobile
     >> >
     >> Sent from my PC.
     >>
     >> > On 17 Sep 2014 9:36 PM, "Danny van Heumen" > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl> > >> > <mailto:danny@dannyvanheumen.nl > <mailto:danny@dannyvanheumen.nl>>> wrote:
     >> >
     >> > Hi Emil,
     >> >
     >> > I've fixed the issue with right-click-join not working. It
    was due
     >> > to
     >> > some inconsistent UI behaviour.
     >> >
     >> > Let me know if you have another clue for your issue with 2 IRC
     >> > connection instances. I haven't encountered it before, so
    without
     >> > additional info I'm kinda dead in the water.
     >> >
     >> > Kind regards,
     >> > Danny
     >> >
     >> > On 09/15/2014 08:22 PM, Emil Ivov wrote:
     >> > > Hey Danny,
     >> > >
     >> > > On Mon, Sep 15, 2014 at 7:52 PM, Danny van Heumen > >> > > <danny@dannyvanheumen.nl > <mailto:danny@dannyvanheumen.nl> <mailto:danny@dannyvanheumen.nl > <mailto:danny@dannyvanheumen.nl>>> wrote:
     >> > >> Hi Emil,
     >> > >>
     >> > >> On 09/14/2014 11:37 PM, Emil Ivov wrote:
     >> > >>> Hey Danny,
     >> > >>>
     >> > >>> I know a few people were on vacation (or in hospital)
    last week
     >> > so
     >> > >>> this hasn't really been tested that much. It's a rather
     >> > substantial
     >> > >>> change so let's not rush it ... especially if you
    don't have
     >> > the time
     >> > >>> to worry about it.
     >> > >>>
     >> > >> I agree that we shouldn't rush it. But, I think people
    might be
     >> > >> overestimating the amount of changes I've made. For
    example, the
     >> > >> "replacers" are 1:1 the same code. (just moved to the
    "replacers"
     >> > >> package and now implementing the Replacer interface)
    And I've
     >> > made some
     >> > >> things explicit such as calling the message HTML after
    it has
     >> > been
     >> > >> formatted.
     >> > >>
     >> > >> I believe that the way I find plain text in between
    HTML tags
     >> > is the
     >> > >> biggest change. (Not to excuse anything, just to point
    out where
     >> > >> weaknesses might be ... ) Because of this, we may be
    processing
     >> > slightly
     >> > >> more content than previously, though I haven't noticed
    it in
     >> > daily use.
     >> > > Damencho, Yana, could you please have a look when possible?
     >> > >
     >> > >>> On a side note I have noticed that unregistering an IRC
     >> > account from
     >> > >>> the accounts panel and then registering it again seems to
     >> > leave you
     >> > >>> with two instances. Have you seen this?
     >> > >>>
     >> > >> Hmm... no, not that I can recall. Do you mean 2
    instances of
     >> > >> connections, or something visually in the UI?
     >> > > Yes I see it appearing twice in the status combo box on
    top of the
     >> > > search field. I am now seeing that I can't reproduce
    this reliably
     >> > > though ... maybe it only happens after a standby? I'll keep
     >> > observing.
     >> > >
     >> > >> In any case I'll play around with
    registering-unregistering a
     >> > bit to see
     >> > >> what I can find.
     >> > >>
     >> > >>> Also, right clicking on a channel and selecting "join"
    seems
     >> > to often
     >> > >>> fail for me whe double clicking the channel usually works.
     >> > Does this
     >> > >>> sound familiar?
     >> > >>>
     >> > >> Actually, I don't have a clue. I would expect the same
    code to
     >> > be called
     >> > >> here. Again, putting it on my TODO list.
     >> > > This is what I see when right clicking:
     >> > >
     >> > > 20:12:58.557 INFO: [1160]
     >> > > impl.protocol.irc.ChatRoomIrcImpl.setUserNickname().687
    Setting
     >> > a nick
     >> > > name for an individual chat room is not supported for IRC.
     >> > > 20:12:58.557 SEVERE: [1160]
     >> > > com.ircclouds.irc.api.IRCApiImpl.executeAsync() Error
    executing
     >> > > command
     >> > > java.nio.channels.ClosedChannelException
     >> > > at
     >> >
    sun.nio.ch.SocketChannelImpl.ensureReadOpen(SocketChannelImpl.java:122)
     >> > > at
     >> > sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:165)
     >> > > at
     >> >
    com.ircclouds.irc.api.comms.SSLSocketChannelConnection.tryReadAndUnwrap(SSLSocketChannelConnection.java:146)
     >> > > at
     >> >
    com.ircclouds.irc.api.comms.SSLSocketChannelConnection.processHandshake(SSLSocketChannelConnection.java:123)
     >> > > at
     >> >
    com.ircclouds.irc.api.comms.SSLSocketChannelConnection.doAnyPendingHandshake(SSLSocketChannelConnection.java:106)
     >> > > at
     >> >
    com.ircclouds.irc.api.comms.SSLSocketChannelConnection.write(SSLSocketChannelConnection.java:67)
     >> > > at
     >> >
    com.ircclouds.irc.api.AbstractCommandServerImpl.execute(AbstractCommandServerImpl.java:19)
     >> > > at
     >> >
      com.ircclouds.irc.api.IRCApiImpl.executeAsync(IRCApiImpl.java:593)
     >> > > at
     >> >
      com.ircclouds.irc.api.IRCApiImpl.joinChannel(IRCApiImpl.java:176)
     >> > > at
     >> >
    net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:639)
     >> > > at
     >> >
    net.java.sip.communicator.impl.protocol.irc.IrcStack.join(IrcStack.java:581)
     >> > > at
     >> >
    net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.join(ChatRoomIrcImpl.java:323)
     >> > > at
     >> >
    net.java.sip.communicator.impl.protocol.irc.ChatRoomIrcImpl.joinAs(ChatRoomIrcImpl.java:356)
     >> > > at
     >> >
    net.java.sip.communicator.impl.muc.MUCServiceImpl$JoinChatRoomTask.run(MUCServiceImpl.java:680)
     >> > >
     >> > > It might be a consequence of a different sequence of
    method calls
     >> > in
     >> > > one case and in the other ... have no idea.
     >> > >
     >> > > Emil
     >> > >
     >> > >>> --sent from my mobile
     >> > >>>
     >> > >>> On 14 Sep 2014 9:45 PM, "Danny van Heumen"
     >> > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>
    <mailto:danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>>
     >> > >>> <mailto:danny@dannyvanheumen.nl
    <mailto:danny@dannyvanheumen.nl>
     >> > <mailto:danny@dannyvanheumen.nl
    <mailto:danny@dannyvanheumen.nl>>>> wrote:
     >> > >>>
     >> > >>> Hi all,
     >> > >>>
     >> > >>> So, has anyone had any problems while testing the new
     >> > formatting code?
     >> > >>>
     >> > >>> I'd like to merge this shortly if possible, since
     >> > otherwise it'll keep
     >> > >>> dragging on. I haven't heard of anyone having
    issues, so
     >> > far, and I
     >> > >>> haven't noticed anything myself.
     >> > >>>
     >> > >>> Kind regards,
     >> > >>> Danny
     >> > >>>
     >> > >>> On 08/28/2014 10:28 PM, Danny van Heumen wrote:
     >> > >>> > Hi all,
     >> > >>> >
     >> > >>> > I am planning to merge a modified implementation
    of the
     >> > message
     >> > >>> > formatting code that processes message that are
    about to
     >> > be
     >> > >>> displayed in
     >> > >>> > the chat conversation window. This code improves
    on the
     >> > >>> following aspects:
     >> > >>> >
     >> > >>> > 1. A different approach to handling (mixed)
    plain text
     >> > and html
     >> > >>> > messages. I process the plain text message once,
    strictly
     >> > >>> leveraging the
     >> > >>> > fact that the code knows exactly when text is
    plain text
     >> > and when it
     >> > >>> > gets turned into HTML (i.e. at least partially
    formatted
     >> > for
     >> > >>> displaying
     >> > >>> > already).
     >> > >>> >
     >> > >>> > 2. Not using <plaintext> tags anymore, since these
     >> > cancel any active
     >> > >>> > formatting, such as light-grey from system messages,
     >> > headings
     >> > >>> and such.
     >> > >>> >
     >> > >>> > 3. Strict HTML escaping for any text that should be
     >> > displayed as is,
     >> > >>> > this includes names of chat rooms, members and
    subjects.
     >> > This is
     >> > >>> > important since IRC channel names allow for
    almost any
     >> > >>> character, so you
     >> > >>> > can create a small HTML document as a chat room
    name,
     >> > and we'd
     >> > >>> like to
     >> > >>> > prevent HTML injection.
     >> > >>> >
     >> > >>> > 4. Now that <plaintext> tags are gone, I've taken a
     >> > different
     >> > >>> approach
     >> > >>> > to processing messages based on the plain text
    parts of
     >> > the message:
     >> > >>> > this approach searches for text in between the
    HTML tags
     >> > for
     >> > >>> processing
     >> > >>> > and escapes it automatically such that you can
    process
     >> > based on the
     >> > >>> > original content, instead of the HTML-escaped
    content.
     >> > >>> >
     >> > >>> > 5. Separate implementations, based on a public
    interface
     >> > for the
     >> > >>> > preprocessing steps that are executed on all
    incoming
     >> > messages.
     >> > >>> There is
     >> > >>> > an interface called 'Replacer' for which a number of
     >> > implementations
     >> > >>> > exist that were previously available as individual
     >> > methods. (A
     >> > >>> separate
     >> > >>> > package is created for these implementations.)
     >> > >>> >
     >> > >>> > 6. Fixed processing URL's in HTML text. (This
    previously
     >> > only
     >> > >>> worked for
     >> > >>> > discovering hyperlinks in plain text message.)
     >> > >>> >
     >> > >>> > 7. Fixed ordering of processing keywords vs.
    hyperlinks:
     >> > >>> previously if a
     >> > >>> > keyword was highlighted, it would break the URL
    and the
     >> > URL
     >> > >>> wouldn't be
     >> > >>> > recognized as such any more.
     >> > >>> >
     >> > >>> > 8. And finally, I've improved to regexp that
    searches
     >> > for plain text
     >> > >>> > content to recognize both tags (by <> brackets) and
     >> > attribute
     >> > >>> values by
     >> > >>> > quotes (") such that we can quite reliably
    distinguish
     >> > parts
     >> > >>> from HTML
     >> > >>> > tags from actual text content.
     >> > >>> >
     >> > >>> > I plan to push these changes by tomorrow evening if
     >> > there are no
     >> > >>> > objections. I'd like to give you all a chance to
    respond
     >> > beforehand,
     >> > >>> > because this touches some quite significant
    code. If I
     >> > need to
     >> > >>> wait to
     >> > >>> > do some more testing, I'm also fine with that.
     >> > >>> >
     >> > >>> > You can find the code at
     >> > >>> >
     >> > https://github.com/cobratbq/jitsi/commits/fix-message-formatting
     >> > >>> > Any feedback is welcome!
     >> > >>> >
     >> > >>> > Kind regards,
     >> > >>> > Danny
     >> > >>> >
     >> > >>> > _______________________________________________
     >> > >>> > dev mailing list
     >> > >>> > dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
     >> > <mailto:dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>>
     >> > >>> > Unsubscribe instructions and other list options:
     >> > >>> > http://lists.jitsi.org/mailman/listinfo/dev
     >> > >>> >
     >> > >>>
     >> > >>> _______________________________________________
     >> > >>> dev mailing list
     >> > >>> dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>> <mailto:dev@jitsi.org
    <mailto:dev@jitsi.org>
     >> > <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>>
     >> > >>> Unsubscribe instructions and other list options:
     >> > >>> http://lists.jitsi.org/mailman/listinfo/dev
     >> > >>>
     >> > >>> _______________________________________________
     >> > >>> dev mailing list
     >> > >>> dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
     >> > >>> Unsubscribe instructions and other list options:
     >> > >>> http://lists.jitsi.org/mailman/listinfo/dev
     >> > >>
     >> > >> _______________________________________________
     >> > >> dev mailing list
     >> > >> dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
     >> > >> Unsubscribe instructions and other list options:
     >> > >> http://lists.jitsi.org/mailman/listinfo/dev
     >> >
     >> > _______________________________________________
     >> > dev mailing list
     >> > dev@jitsi.org <mailto:dev@jitsi.org> <mailto:dev@jitsi.org
    <mailto:dev@jitsi.org>>
     >> > Unsubscribe instructions and other list options:
     >> > http://lists.jitsi.org/mailman/listinfo/dev
     >> >
     >> > _______________________________________________
     >> > dev mailing list
     >> > dev@jitsi.org <mailto:dev@jitsi.org>
     >> > Unsubscribe instructions and other list options:
     >> > http://lists.jitsi.org/mailman/listinfo/dev
     >>
     >> _______________________________________________
     >> dev mailing list
     >> dev@jitsi.org <mailto:dev@jitsi.org>
     >> Unsubscribe instructions and other list options:
     >> http://lists.jitsi.org/mailman/listinfo/dev
     >
     > _______________________________________________
     > dev mailing list
     > dev@jitsi.org <mailto:dev@jitsi.org>
     > Unsubscribe instructions and other list options:
     > http://lists.jitsi.org/mailman/listinfo/dev

    --
    https://jitsi.org

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev