[jitsi-dev] Stripping html from content in "original_message" attribute (ChatConversationPanel)


#1

Hi devs,

I suspect that I have found the main cause of all the copy-paste
problems from the chat window (i.e. ChatConversationPanel).

Inner html that is, such as that stored in the "original_message"
attribute, *sometimes* results in bad copy data. I say "some times"
because if you retrieve full text content (programmatically via html
document instance), then it has *always* up to now resulted in a nice
clean copy. However, often when you select parts of a chat conversation
and copy that, you will get partial html copied with it - even parts of
the original_message content, I believe.

I have tried various ways of escaping html, using only double quotes (")
in html to simplify escaping, manually escaping and dumping content to
stdout. In short, I don't think we are doing anything wrong, currently,
but still copying is an issue.

When I make "original_message" attribute empty it is enough of a change
such that I cannot reproduce the copying-issues anymore. I suspect these
copy-errors occur, because of where we start/end a selection, which may
be an unfortunate point in the underlying html content.

Now, I am wondering. Would it be a problem if we strip html from the
"original_message" before storing it as such?
I don't know all protocols equally well, so I'd like your opinion(s) on
this.

Danny


#2

I have tried various ways of escaping html, using only double quotes (")
in html to simplify escaping, manually escaping and dumping content to
stdout. In short, I don't think we are doing anything wrong, currently,
but still copying is an issue.

What about base64 (or whatever base) encoding?

When I make "original_message" attribute empty it is enough of a change
such that I cannot reproduce the copying-issues anymore. I suspect these
copy-errors occur, because of where we start/end a selection, which may
be an unfortunate point in the underlying html content.

Now, I am wondering. Would it be a problem if we strip html from the
"original_message" before storing it as such? I don't know all protocols
equally well, so I'd like your opinion(s) on this.

What is the usage of that attribute anyway? It seems to me that we're misusing the view (the UI) to store model data for whatever reason.

Danny

Ingo


#3

I have tried various ways of escaping html, using only double quotes (")
in html to simplify escaping, manually escaping and dumping content to
stdout. In short, I don't think we are doing anything wrong, currently,
but still copying is an issue.

What about base64 (or whatever base) encoding?

Hmm... why didn't I think of that :stuck_out_tongue:
We could easily modify this, this is all internal workings. No public
infrastructure there.

When I make "original_message" attribute empty it is enough of a change
such that I cannot reproduce the copying-issues anymore. I suspect these
copy-errors occur, because of where we start/end a selection, which may
be an unfortunate point in the underlying html content.

Now, I am wondering. Would it be a problem if we strip html from the
"original_message" before storing it as such? I don't know all protocols
equally well, so I'd like your opinion(s) on this.

What is the usage of that attribute anyway? It seems to me that we're misusing the view (the UI) to store model data for whatever reason.

It isn't used much. It seems to be used primarily (if not only) for
message correction.

I did a quick check. I don't think we have a "message listener"
implementation that serves as a message store. We have several that
store message for purpose of history and such, but all with a particular
goal and limitations. In time it could be useful to have a general
purpose store which can be used for different purposes. Anyways, going
off topic here ...

Danny

···

On 15-12-14 22:21, Ingo Bauersachs wrote:

Danny

Ingo

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


#4

Currently fixed with base64-encoding the message. This does the trick
pretty well. (I've confirmed that message correction still works.)

I noticed that what we store as the original message is already partly
processed. Will have a look to see whether it is better to store the
original original message. Isn't anything serious though.

Any feedback w.r.t. copy-paste behaviour is welcome! I probably haven't
ironed out all the issues.

Danny

···

On 15-12-14 22:21, Ingo Bauersachs wrote:

I have tried various ways of escaping html, using only double quotes (")
in html to simplify escaping, manually escaping and dumping content to
stdout. In short, I don't think we are doing anything wrong, currently,
but still copying is an issue.

What about base64 (or whatever base) encoding?

When I make "original_message" attribute empty it is enough of a change
such that I cannot reproduce the copying-issues anymore. I suspect these
copy-errors occur, because of where we start/end a selection, which may
be an unfortunate point in the underlying html content.

Now, I am wondering. Would it be a problem if we strip html from the
"original_message" before storing it as such? I don't know all protocols
equally well, so I'd like your opinion(s) on this.

What is the usage of that attribute anyway? It seems to me that we're misusing the view (the UI) to store model data for whatever reason.

Danny

Ingo

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


#5

Now, I am wondering. Would it be a problem if we strip html from the
"original_message" before storing it as such? I don't know all protocols
equally well, so I'd like your opinion(s) on this.

What is the usage of that attribute anyway? It seems to me that we're
misusing the view (the UI) to store model data for whatever reason.
It isn't used much. It seems to be used primarily (if not only) for
message correction.

I did a quick check. I don't think we have a "message listener"
implementation that serves as a message store.

There's no need for a shared in-memory message storage.

We have several that
store message for purpose of history and such, but all with a particular
goal and limitations. In time it could be useful to have a general
purpose store which can be used for different purposes. Anyways, going
off topic here ...

What I meant was in the direction of the MVC-pattern. There should be some
list/array/whatever in the model (whatever that currently is) that stores
all messages which the UI /currently/ shows. My guesswork would be that
there's no such thing and the view serves as the model, making things
unnecessarily complex.

Danny

Danny

Ingo

Ingo

···

On 15-12-14 22:21, Ingo Bauersachs wrote:


#6

Hi Ingo,

Now, I am wondering. Would it be a problem if we strip html from the
"original_message" before storing it as such? I don't know all protocols
equally well, so I'd like your opinion(s) on this.

What is the usage of that attribute anyway? It seems to me that we're
misusing the view (the UI) to store model data for whatever reason.
It isn't used much. It seems to be used primarily (if not only) for
message correction.

I did a quick check. I don't think we have a "message listener"
implementation that serves as a message store.

There's no need for a shared in-memory message storage.

I mean that this could serve as both: 1. the model for the
ChatConversationPanel (the view)., 2. the reference store for the most
recent message view (I think part of Contact list), 3. model for history
view. (3rd may not make sense, I'm not sure what history does
differently except for loading log files for old conversations.)

We have several that
store message for purpose of history and such, but all with a particular
goal and limitations. In time it could be useful to have a general
purpose store which can be used for different purposes. Anyways, going
off topic here ...

What I meant was in the direction of the MVC-pattern. There should be some
list/array/whatever in the model (whatever that currently is) that stores
all messages which the UI /currently/ shows. My guesswork would be that
there's no such thing and the view serves as the model, making things
unnecessarily complex.

This is what I meant with the in-memory store, as explained above. And
no, I haven't found anything else that takes on this function.

Danny

···

On 15-12-14 22:51, Ingo Bauersachs wrote:

On 15-12-14 22:21, Ingo Bauersachs wrote:

Danny

Danny

Ingo

Ingo

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