1953747 - Special characters in folders are displayed wrong ( ä → &AOQ- etc)

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking: IMAP, defect)

Description

[Kay]

Attachment: Screenshot 2025-03-13 122517.png

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

Steps to reproduce:

Upgrade to TB 136

Actual results:

IMAP-Folders with special characters like ä, ö, ü are displayed wrong
ä → &AOQ-
ü → &APw-

This was no problem in TB 128

Expected results:

Correct display of special characters

Comment 1

[Magnus Melin [:mkmelin]]

That does work in general. I don't see the issue in my setup.

Comment 3

[Magnus Melin [:mkmelin]]

Please get a regression range. https://mozilla.github.io/mozregression/ can help.

An IMAP protocol log may also shed some light on this. https://wiki.mozilla.org/MailNews:Logging

Comment 4

[ILIA]

(In reply to Magnus Melin [:mkmelin] from comment #1)

That does work in general. I don't see the issue in my setup.

Me and other users have this bug. Screenshots were attached by me and other users.
Also, when I updated my Thunderbird 128.x.x to 136.0, connection to mail server has been lost (IMAP protocol is used).

Comment 5

[ILIA]

(In reply to Magnus Melin [:mkmelin] from comment #3)

Please get a regression range. https://mozilla.github.io/mozregression/ can help.

An IMAP protocol log may also shed some light on this. https://wiki.mozilla.org/MailNews:Logging

I'm not an IT specialist. Coukd uou please explain what "regression range" means and what data do you want from me and others users faced this bug to provide?

Comment 6

[Magnus Melin [:mkmelin]]

Regression range will say which version (which changesets) introduce the bug.

You don't need to be a specialist. You run the https://mozilla.github.io/mozregression/ tool and follow instructions there. Then provide the info the tool comes up with back here in the bug report

Comment 7

[ILIA]

(In reply to Magnus Melin [:mkmelin] from comment #6)

Regression range will say which version (which changesets) introduce the bug.

You don't need to be a specialist. You run the https://mozilla.github.io/mozregression/ tool and follow instructions there. Then provide the info the tool comes up with back here in the bug report

I have downloaded MozRegression but the video instruction is unclear and for much older version of MozRegression.
Could you please provide step-by-step guide to use MozRegression properly?

Comment 9

[Wayne Mery (:wsmwk)]

Background - the tool is going to automate the discovery process for you, using daily channel (release type) development builds i.e. trunk, after you fill in some basic information. So unless you are already using daily channel it is not going to use the channel you are currently running, which is either beta, esr or release builds.

1. Download and install https://github.com/mozilla/mozregression/releases/download/6.3.0/mozregression-gui-signed.exe
2. Start the installed program.
3. Step by step starts at 2:10 in the video https://youtu.be/IwrWot3jVFI?t=128 - where fill in the blanks. The video is old, some of the initial UI choices have changed. Pick the scissors icon to start the bisection wizard
4. Basic Configuration - Pick Thunderbird product. (or thunderbird-l10n if you prefer a localized version of thunderbird)
5. Click Continue.
6. Profile Selection - if you want to use your existing profile you can find it at Help > Troubleshooting Information.
   6a. Clone choices: skip if you just want to create a new profile (and fill in your account information. "CLONE if you want to clone your existing profile every time the regression tool iterates, CLONE-FIRST tends to be a good choice, to clone your existing profile on just the first iteration, REUSE if you simply want to use your existing profile for every iteration (this could affect your production data)
7. Click continue
8. Build Selection: Pick the range of builds to be tested. This is where it gets complicated, because your choices depend on what channel you have been using, and whether you want to a release number, buildid or date. Approximate values can be fine. [1]
9. Click Done

The hunt process will begin. The "Progress" pane will show the history of what builds are being used. The "Log" pane shows detailed progress. . To stop at any point, click the "X" icon.

[1] build ranges:

• If you are using Thunderbird esr channel, set First known bad build to the date where you first noticed the problem (or visit Help > Troubleshooting Information and use date from the "Build ID" which is in the form YYYYMMDD). Set Last known good build to one year earlier, in other words subtract one year from First known bad build.
• If you are using channels beta, release or daily it is probably easiest to change "date" to "release, and use release numbers rather than date. For First known bad build use the first release number where you noticed it is failing (don't include decimal points). If you don't know when the problem started, subtract 10 and use that for Last known good build.

Comment 10

[Magnus Melin [:mkmelin]]

We need more info to get anywhere here.

Comment 11

[ILIA]

(In reply to Magnus Melin [:mkmelin] from comment #10)

We need more info to get anywhere here.

I've done nothing but the problem doesn't occur now... Don't mind what happened...

Comment 12

[Corey Bryant]

Ilia, I'm closing this bug for now. Please feel free to re-open this bug in the future if the issue comes back.