1718331 - Performance issue with large log files sent thru mail - content related.

Status: UNCONFIRMED

(Thunderbird :: Mail Window Front End, enhancement)

Description

[AC]

Attachment: sample_procmon_log.txt

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

Viewed nodejs log file sent thru email.

Actual results:

Mailing a large nodejs log file causes 60+ second delay each time the message is viewed. Procmon log on Windows shows that Thunderbird is scanning for certain words as URLs.

This occurs whenever a colon followed by a alphanum character (and maybe others) but not where double-quotes or spaces follow the colon. It appears to be some sort of url protocol lookup.

Nodejs log lines:
{"message":"stage 1 Miss:1 Found:0","level":"error"}
{"message":"stage 1 Miss:0 Found:4","level":"error"}

Additional test lines demonstrating where colon-character sequences trigger the scans. The json keys are not scanned, but the colon-char sequences in the message text are scanned.
{"message":"This is not scanned","level":"error"}
{"message":"This is also not: scanned","level":"error"}
{"message":"But this one is:scanned","level":"error"}
{"country":"AD","message":"scansmyerrorcode:274","name":"Pas de la Casa","lat":"42.54277","lng":"1.73361"},
{"country":"AD","message":"doesnotscansmyerrorcode: 274","name":"Pas de la Casa","lat":"42.54277","lng":"1.73361"},

While this is typically a fast process for single occurrences, a nodejs log file with 30,000 lines as above stalls Thunderbird for about a minute while every occurrence of "stage 1 miss", "miss", and "found" are scanned, resulting in 90,000+ registry lookups.

If the colon-character sequence is avoided, the scans do not occur and logs display within a second. Incoming logs are not always under our control.

RegOpenKey HKCU\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\stage1miss NAME NOT FOUND Desired Access: Read

See attached for full procmon (registry monitor) log example.

Expected results:

Expected behavior would be to not impact performance.

Perhaps pre-scan and cache the HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Shell\Associations\UrlAssociations list of protocols so that a scan for each entry is not required. Or use a preconfigured list of common protocols.