mIRC Home    About    Download    Register    News    Help

Print Thread
7.68.933 - "/cap req -echo-message" display bug. #270236 03/05/22 05:39 PM
Joined: Feb 2011
Posts: 403
K
KindOne Offline OP
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
K
Joined: Feb 2011
Posts: 403
Entering the following command causes all my text after the 'cap req -echo-message' to be gray.

I tested on Libera.Chat and Snoonet.


Code
//var %x 6 | while (%x > 3) { msg $active %x | dec %x } | cap req -echo-message | var %x 3 | while (%x) { .timer 1 3 msg $active %x | dec %x } 


* Now talking in ##testing123
<KindTwo> 6
<KindTwo> 5
<KindTwo> 4
<KindTwo> 3
<KindTwo> 2
<KindTwo> 1


Entering this still causes my text to be gray:
Code
/cap req echo-message


<KindTwo> Test


https://imgur.com/7ssial4


Update:

After more testing found another bug. This one is a bit more strange as I can only replicate on Libera.Chat.

Code
alias echo-message_bug {
  var %x 6
  while (%x > 3) {
    msg $active %x 
    dec %x 
  }

  cap req -echo-message

  var %x 3
  while (%x) { 
    .timer 1 3 msg $active %x
    dec %x 
  }

  .timer 1 5 cap req echo-message 

  .timer 1 7 msg $active Testing123
  .timer 1 9 msg $active Testing1234567890
}


This only happens on Libera.Chat.

<KindTwo> 6
<KindTwo> 5
<KindTwo> 4
<KindTwo> Testing123
<KindTwo> Testing1234567890
<KindTwo> 1
<KindTwo> Testing123
<KindTwo> Testing1234567890


https://imgur.com/yGC60Xn

------

Snoonet:

<@KindTwo> 6
<@KindTwo> 5
<@KindTwo> 4
<@KindTwo> 3
<@KindTwo> 2
<@KindTwo> 1

<@KindTwo> Testing123
<@KindTwo> Testing1234567890

https://imgur.com/vGPgMOl

Last edited by KindOne; 03/05/22 08:24 PM. Reason: another issue and images

irc.swiftirc.net #msl (mIRC Scripting Language)
Re: 7.68.933 - "/cap req -echo-message" display bug. [Re: KindOne] #270238 03/05/22 08:45 PM
Joined: Dec 2002
Posts: 5,132
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,132
Thanks for your bug report. I have added support for processing -echo-message (indicating that it has been disabled on the server) in the next beta.

Re: 7.68.933 - "/cap req -echo-message" display bug. [Re: KindOne] #270243 04/05/22 12:02 PM
Joined: Dec 2002
Posts: 5,132
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,132
Quote
After more testing found another bug. This one is a bit more strange as I can only replicate on Libera.Chat.

This is the same issue :-) Please wait until the next beta before testing -echo-message further as it is not supported in the current beta.

The reason you are seeing different behaviours is that Libera.Chat only supports echo-message, while Snoonet supports echo-message and labeled-response. The parsing of their echoed messages will be different since, without labeled-response, there is no clear correlation between sent and echoed messages. I have described this issue in beta.txt.

In fact, it may even be the case that different ircds handle enabling/disabling echo-message differently, and there may be a timing issue since echoed messages will only be returned once a message has reached its destination. So, by mixing multiple enabled/disabled/send/receive without/without labeled-response, the results could be interesting.

This is why I may decide to not support echo-message without labeled-response in the final release. In that case, if a user decides to manually enable echo-message without labeled-response, they will then also need to write a script to handle echoed messages themselves.

Update: I tested your script on Libera.Chat. In some cases, it showed the expected result, in other cases, it showed your above result, with the following debug information:

Quote
-> lithium.libera.chat PRIVMSG #thisisatest :6
-> lithium.libera.chat PRIVMSG #thisisatest :5
-> lithium.libera.chat PRIVMSG #thisisatest :4
-> lithium.libera.chat CAP req -echo-message
-> lithium.libera.chat PRIVMSG #thisisatest :3
-> lithium.libera.chat PRIVMSG #thisisatest :2
-> lithium.libera.chat PRIVMSG #thisisatest :1
-> lithium.libera.chat CAP req echo-message
-> lithium.libera.chat PRIVMSG #thisisatest :Testing123
-> lithium.libera.chat PRIVMSG #thisisatest :Testing1234567890
<- @account=nick :nick!~user@host PRIVMSG #thisisatest :6
<- @account=nick :nick!~user@host PRIVMSG #thisisatest :5
<- @account=nick :nick!~user@host PRIVMSG #thisisatest :4
<- :lithium.libera.chat CAP nick ACK :-echo-message
<- :lithium.libera.chat CAP nick ACK :echo-message
<- @account=nick :nick!~user@host PRIVMSG #thisisatest :Testing123
<- @account=nick :nick!~user@host PRIVMSG #thisisatest :Testing1234567890
-> lithium.libera.chat QUIT :

Dissecting this: notice that even though we sent two CAP reqs, we did not receive confirmation from the server of the CAP req changes until after several PRIVMSGs were sent. From mIRC's viewpoint, the echo-message status only changes once it has received the CAP ACK confirmation from the server. So in the above series of events, there is a disconnect between what mIRC thinks should/should not be echoed and what the server thinks should/should not be echoed. When combined with the lack of labeled-response on Libera.Chat, and perhaps lag/timing, the result is not going to look pretty.

In the above case, mIRC sends the "CAP -req -echo-message" to disable echo-message, and then a few seconds later sends "3" "2" "1". The server treats "3" "2" "1" as not needing echoes because echo-message has been disabled but mIRC does not receive the "CAP ACK -echo-message", confirming that echo-message has been disabled (which the server could possibly decline with a NAK), until after these messages are sent, so as far as mIRC is concerned echo-message is still enabled for them, expects echoes for them, grays them out, etc.

I would say that, while it's great that you are testing this, echo-message is very likely meant to be either enabled or disabled :-)

Last edited by Khaled; 05/05/22 11:19 AM.