1492844 - When multiple dictionaries are installed, the context menu shows all the possible sub-dictionaries of those languages

Status: NEW

(Firefox :: Menus, defect, P3)

Description

[El Stellino]

Attachment: photo5843726645058448797.jpg

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180704132104

Steps to reproduce:

FF came with en-US, that I didn’t manage to ditch.
I installed the dictionaries I use:
it-IT (Italian)
fr-FR (French)
es-ES (Spanish)
en-GB (British English)


Actual results:

Those dictionaries installed no problem, but when the spell check is activated, right clicking on the text and opening the context menu "Languages" displays an impossible list of other dictionaries, they are the same languages and all their possible locales.
I started using Nightly to avoid this, as I am a translator and need to switch between dictionaries rather often (and swiftly) during the day: over there, no problem.
Some time ago I also created a new FF profile, and had the same problem. Now Firefox is running in safe mode, and it still shows 32 languages.
Please see attachment.



Expected results:

I was expecting to see only the 4 dictionaries I installed that I was intending to use without fishing them out amongst other 28 useless dictionaries.

Comment 1

[u554753]

Hi,

Thanks for reporting this issue. Can you specify in your STR on how you installed the dictionaries? Did you do it through a use of an add-on or through about:preferences? If it's the former, please attach your about:support info.

Going to set the component as Core: Internationalization for the time being so this can be looked at. Correct if this is not the right component. Thanks.

Comment 2

[El Stellino]

Hello, 

Thank you for moving it to the right place.

I installed the dictionaries as add-ons, right clicking on a word while typing, and clicking on the Languages>add dictionaries… context menu, which opened at https://addons.mozilla.org/en-US/firefox/language-tools/.

Here is my about:support info. Please note that not in safe mode a good ¾ of those add‑ons are set to false, I usually just use a few of them, and have to delete all the unused ones:
https://paste.ubuntu.com/p/TJFxSTJRh5/

Thanks!

PS: sorry, I don’t know the meaning of STR, I hope the information provided above is sufficient.

Comment 3

[El Stellino]

Hello, I’ve just noticed this and I don’t know if it’s useful: the same exact problem presents itself in Thunderbird 60.2.1
(64-bit).

Comment 4

[Jared Wein [:jaws] (please needinfo? me)]

Can you please test with mozregression to see when this started happening? See https://mozilla.github.io/mozregression/ for more information.

Comment 5

[El Stellino]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #4)

Can you please test with mozregression to see when this started happening? See https://mozilla.github.io/mozregression/ for more information.

Thanks Jared, I’ve already downloaded it but I will try it later in the week. as I am really busy with work right now.
Thanks for taking the time.

Comment 6

[Jared Wein [:jaws] (please needinfo? me)]

Have you had a chance to test with mozregression?

Comment 7

[Mike Conley (:mconley) (:⚙️)]

Hi El Stellino, any updates here?

Comment 8

[El Stellino]

Hello, sorry, I have been particularly busy recently, I run it only once but as I didn't have much time I didn't go further. I saw though that it had s preference of picking Nightly to be checked, a browser I use because it doesn't have this problem.
Then, I also don't really know when this issue started, but I know that it has been quite some time (a couple of years at least) and for this reason it's difficult to find the correct time frame between two builds.
Thanks.

Comment 9

[Jared Wein [:jaws] (please needinfo? me)]

Could I ask that you try again? With mozregression, you can enter in dates that are multiple years apart and it will only take about 10 minutes to find what day this started happening. This will greatly increase the chances of the bug getting fixed.

Comment 10

[El Stellino]

Of course you can, no problem.
I was about to try in fact, but my problem with this application is that even when I select builds, mozregression opens for some reason exclusively Nightly, which is in my system precisely because it doesn’t present that issue.
I selected as a range 65-38, as now on standard FF I am using 66. But it only loaded 2 builds of Nightly were the problem didn’t present itself, as it never did.
And of course…
"5:07.44 ERROR: Build was expected to be bad! The initial good/bad range seems incorrect."

Would you please indicate me how I select the standard Firefox in mozregression? I can’t find how to do it.
Thank you in advance.

Sorry, I didn’t mean to clear the needinfo request, it was ticked on default

Comment 11

[El Stellino]

[Tracking Requested - why for this release]:

Comment 12

[El Stellino]

Recently I decided to revamp my spare laptop running Windows 10 and rather slow, installing in dual boot Linux Mint 20.2 (as in the main computer where this very problem appeared first).

Well, new installation, new username, new identity for Firefox, didn’t log in to synchronize nor install anything, and… 44 (FORTY‑FOUR) dictionaries in the context menu Languages in Firefox.
In the dictionaries tab in Firefox, just EN-US and EN-CA, unremovable, built in the browser.

Then, this:
https://support.mozilla.org/en-US/questions/761598

Now, what is the point in installing dictionaries in Firefox, if it then takes them from usr/share/hunspell/ anyway?
This is Firefox (and Thunderbird), not Libreoffice.

I’d say that’s a bug that needs fixing, but then I’m certainly not an expert.

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.