898777 - The number "80" is not displayed with colour

Status: RESOLVED FIXED

(Other Applications Graveyard :: ChatZilla, defect)

Description

[Yizhe]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

1. Type "%B80" in input line, press Enter.
2. Type "%B79 80 81" in input line, press Enter.
3. Replace "%B" in steps 1 and 2 with any other formatting code.
4. Receive an IRC message with formatting that contains "80".



Actual results:

1. The "80" is displayed without bold.
2. The "79" and "81" are displayed in bold, but "80" is plain.
3. The results are the same for other formatting codes.
4. I first observed this behaviour in an IRC channel that displays various numbers with colour. "80" always seemed to appear without colour.



Expected results:

In each case, the "80" should be displayed in the same style as the surrounding text.

If each individual digit is given a colour code ("%C04,018%C04,010") then it is not a problem. However this workaround does not work for the "%B" and "%U".

This problem seems to occur when "80" is directly preceeded by a formatting code and when " 80 " appears in a formatted line, where 80 is directly preceded and proceeded by a space.

Comment 1

[Yizhe]

Is this related to the fix for bug #65861?

Comment 2

[:Gijs (he/him)]

(In reply to Yizhe from comment #1)
> Is this related to the fix for bug #65861?

Hard to tell, that bug is so old and was fixed with a mass merge which makes it impossible to see what was changed to fix it. We'll just have to investigate this one - fortunately you gave good steps to reproduce. I'll try and have a look later today if nobody beats me to it.

Comment 3

[Tony Mechelynck [:tonymec]]

I can reproduce the bug on ChatZilla 0.9.90.1 running in Firefox 17.0.8esrpre, and in "ChatZilla 0.9.90.1 or later" in SeaMonkey 2.22a1, as follows:

Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Firefox/17.0
http://hg.mozilla.org/releases/mozilla-esr17/rev/cab06c406ed8

Mozilla/5.0 (X11; Linux i686 on x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 SeaMonkey/2.22a1 ID:20130726003001 c-c:55edd6e9957e m-c:46d73e889cb4

I used a /query from one to the other to avoid spamming public channels. In all cases the number 80 gets no styling while other numbers do. The bug only happens if the string 80 is "one word": 798081, 880, 800 are all styled normally.

Comment 4

[Robert Utasi [:hunboy]]

(In reply to Tony Mechelynck [:tonymec] from comment #3)
> I used a /query from one to the other to avoid spamming public channels. In
> all cases the number 80 gets no styling while other numbers do. The bug only
> happens if the string 80 is "one word": 798081, 880, 800 are all styled
> normally.

Tony, I localised the reason and found several (about hundreds) strings are not mungered correctly, such as B0  XO 
I just need 30 hours long days to try to fix it. I have ideas what to do, just I need checking them.

Comment 5

[Robert Utasi [:hunboy]]

Actually we should name this as "undefined fake smileys" which ones fit to munger.addRule "face" regexp, but not defined in insertSmiley function as a real smiley. Perhaps all of these ones are fake smileys: [B8Xx][PpSs0oO] . We can find more ones playing vith the - char ps: X-O

Comment 6

[Robert Utasi [:hunboy]]

my current problem is - if I know well - the Chomsky3 grammar doesn't know the & connection, only | one. We need filter somehow out this match: [B8Xx]-{0,1}[PpSs0oO]

Comment 7

[Robert Utasi [:hunboy]]

/((^|\s)((?:[>]?[=:;(][~']?[-^v"]?(?:[)|(PpSs0oO\?\[\]\/\\]|D+)|>[-^v]?\)|[oO9][._][oO9])|(?:[>]?([B8](?![PpSs0oO])[~']?[-^v"]?(?:[)|(PpSs0oO\?\[\]\/\\]|D+)|>[-^v]?\)|[oO9][._][oO9]))|([Xx]-*D))(\s|$))/

this regexp filters out some of them and allows XD smiley directly, but we still can fool teh munger with the - char

Comment 8

[:Gijs (he/him)]

(In reply to Robert Utasi [:hunboy] from comment #7)
> /((^|\s)((?:[>]?[=:;(][~']?[-^v"]?(?:[)|(PpSs0oO\?\[\]\/\\]|D+)|>[-
> ^v]?\)|[oO9][._][oO9])|(?:[>]?([B8](?![PpSs0oO])[~']?[-^v"]?(?:
> [)|(PpSs0oO\?\[\]\/\\]|D+)|>[-^v]?\)|[oO9][._][oO9]))|([Xx]-*D))(\s|$))/
> 
> this regexp filters out some of them and allows XD smiley directly, but we
> still can fool teh munger with the - char

AIUI we will try to munge things both ways (ie, smiley and formatting code), and prefer whichever hits at an earlier index. What I don't understand is why that isn't working here and/or why the not-quite-a-smiley then breaks further formatting of the string. I'd prefer to fix that rather than the regexp, if that's possible.

Comment 9

[James Ross]

The issue is that we don't handle mis-matches of the face regex correctly: note how the link and rheet (!) mungers use insertText() to add any "non-matched" text. That's how you should insert text that didn't match (or call back in to the munger, or use a function instead of regex to match, etc.).

(For reasons that are probably due to the way mIRC codes work, the colouring/bold/etc. effects are only applied at the tightest level of the munger - when it finally spits out bits of text.)

So any munger inserting raw text (I'm also looking at you, insertChannelLink and insertQuote) might be suspect. If it calls back in to the munger, it's fine.

Comment 10

[Robert Utasi [:hunboy]]

Yes, this is the reason why I stopped looking for more fake smilies, 1km long regexp is not the best solution especially if doesn't fix basically the problem.

Comment 11

[Robert Utasi [:hunboy]]

Attachment: use callback for mis-matches

Patch is based on Comment 9

Comment 12

[James Ross]

Comment on attachment 787758 [details] [diff] [review]
use callback for mis-matches

Review of attachment 787758 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, r+, thanks!

Comment 13

[:Gijs (he/him)]

And land this.

Comment 14

[:Gijs (he/him)]

https://hg.mozilla.org/chatzilla/rev/5155610c9fc3