1881830 - Flatpak: dictionaries other than en-US not available after update to Firefox 123

Status: RESOLVED FIXED

(Firefox Build System :: Third Party Packaging, defect, P3)

Description

[vicentehc]

Attachment: bug spellchecker

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:123.0) Gecko/20100101 Firefox/123.0

Steps to reproduce:

The dictionary for the Spanish spell checker is installed but does not appear as selectable since version 123.

Actual results:

Only the English dictionary is available

Expected results:

The Spanish dictionary should be available as usual

Comment 1

[vicentehc]

Attachment: dictionaries

Comment 2

[vicentehc]

From flathub.

Comment 3

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

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 4

[Francesco Lodolo [:flod]]

Based on the screenshot, you installed language packs, while you need dictionaries (which will show up in the Dictionaries tabs, not Languages in about:addons).

You can install one from the Dictionaries column here
https://addons.mozilla.org/firefox/language-tools/

Comment 5

[vicentehc]

The bug is not invalid. The language pack includes the dictionary. This is a regression. Since updating the flatpak package (firefox/ mozilla official) to version 123 I have no spell check for my language.

Comment 6

[vicentehc]

Sorry. It is true that if I install the dictionary by hand now I do have spell checker.

Anyway, this must be a bug of the flatpak package maintainer who has removed it. In previous versions there was no need to install anything by hand.

Comment 7

[vicentehc]

https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/docker/firefox-flatpak

Comment 8

[Francesco Lodolo [:flod]]

A language pack doesn't include a spell checker, they're completely separate type of add-ons.

On Linux, a standard installation of Firefox has access to spell checkers installed on the system, since they both use Hunspell. With that said, I don't know if flatpak isolates Firefox from this.

Were you using flatpak also with Firefox 122? If so, it's either a regression or a feature. Reopening, as there is also another person reporting the same issue.

Comment 10

[vicentehc]

Yes, I am using the Firefox flatpak package. No doubt it is a regression.

I'm going to try to reference some people who are involved in its packaging. From here:

https://hg.mozilla.org/mozilla-central/log/tip/taskcluster/docker/firefox-flatpak/runme.sh

Thanks.

Comment 11

[bbhtt]

Hi, does running it as flatpak run --env=DICPATH=/usr/share/hunspell org.mozilla.firefox make the system spell checkers show up in the context menu?

This is likely related to prefs being migrated from prefs.js to distribution.ini in https://hg.mozilla.org/integration/autoland/rev/0fc123de30da and https://github.com/mozilla-partners/flatpak/pull/1

Comment 12

[vicentehc]

(In reply to bbhtt from comment #11)

Hi, does running it as flatpak run --env=DICPATH=/usr/share/hunspell org.mozilla.firefox make the system spell checkers show up in the context menu?

Yes! That's the way it works.

This is likely related to prefs being migrated from prefs.js to distribution.ini in https://hg.mozilla.org/integration/autoland/rev/0fc123de30da and https://github.com/mozilla-partners/flatpak/pull/1

Is it going to be solved or does it require intervention from all users? Thanks.

Comment 13

[Emerson Bernier]

(In reply to bbhtt from comment #11)

Hi, does running it as flatpak run --env=DICPATH=/usr/share/hunspell org.mozilla.firefox make the system spell checkers show up in the context menu?

This is likely related to prefs being migrated from prefs.js to distribution.ini in https://hg.mozilla.org/integration/autoland/rev/0fc123de30da and https://github.com/mozilla-partners/flatpak/pull/1

This is wieird since before and after the changes about:config still shows:

spellchecker.dictionary_path: /usr/share/hunspell

So settings in distribution.ini are read yet for some reason aren't effective.

Restoring default-preferences.js fixes this for me but someone need to check why this makes difference in behavior.

Comment 14

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

Set release status flags based on info from the regressing bug 1795998

:gerard-majax, since you are the author of the regressor, bug 1795998, could you take a look?

For more information, please visit BugBot documentation.

Comment 15

[:gerard-majax]

Mike looks like something went wrong. Based on comment #12 maybe we just need to add the DICPATH env variable ? We already do that for snap anyway

Comment 16

[:gerard-majax]

Attachment: Bug 1881830 - Pass DICPATH env var to Flatpak r?mkaply!

Comment 17

[Mike Kaply [:mkaply]]

I know we've had spellchecker paths in distribution.ini before. I don't really understand why it's not working. But this seems like a better idea anyway.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a5c1fbe78e43
Pass DICPATH env var to Flatpak r=mkaply,emersonbernier

Comment 19

[:gerard-majax]

Comment on attachment 9382499 [details]
Bug 1881830 - Pass DICPATH env var to Flatpak r?mkaply!

Beta/Release Uplift Approval Request

• User impact if declined: Spellchecking unavailable outside of en-US
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Only add one env variable to the flatpak build
• String changes made/needed: N/A
• Is Android affected?: No

Comment 20

[Robert McQueen [:ramcq]]

I'm a little worried this is a workaround and we don't understand the root cause of the problem. We removed the prefs.js on the basis of moving those settings to distribution.ini. A commenter on the #flatpaks Matrix room commented that they are also now seeing the default browser check in the Flatpak, which is also included in the distribution.ini - could all of our distribution.ini settings not be working? Have they been deployed correctly? I don't understand how they are applied inside Firefox.

Comment 21

[Mike Kaply [:mkaply]]

A commenter on the #flatpaks Matrix room commented that they are also now seeing the default browser check in the Flatpak

That's odd because the default browser check definitely works via distribution.ini (and has for years).

It was indicated when going to about:config, the pref is there, so distribution.ini is definitely read.

There have been cases in the past where some prefs set via distribution.ini are read to late and I believe that this is the case.

Unfortunately the thing we are still missing with Flatpak is a good way to build it locally which would allow me to test this more.

Comment 22

[Robert McQueen [:ramcq]]

(In reply to Mike Kaply [:mkaply] from comment #21)

That's odd because the default browser check definitely works via distribution.ini (and has for years).

Exactly! But the prefs.js we removed in https://bugzilla.mozilla.org/show_bug.cgi?id=1795998 also contained a duplicated/redundant preference to remove the browser check, which has now gone.

Unfortunately the thing we are still missing with Flatpak is a good way to build it locally which would allow me to test this more.

Indeed; I think if you set (these)[https://github.com/mozilla/gecko-dev/blob/master/taskcluster/docker/firefox-flatpak/runme.sh#L9-L17] environment variables to paths roughly approximating / simulating what taskcluster sets them to, you'd be able to build the Dockerfile and run the container locally, and it would build you a corresponding flatpak. I was hoping I could find the relevant instance of taskcluster and eyeball the logs for the relevant release train, and that would give me convenient values to test, but I can't seem to find it. I'd be happy to help make a test.sh or something in we could keep this folder that did all of the relevant steps to mock out enough of the environment and build a test flatpak.

Comment 23

[Robert McQueen [:ramcq]]

(In reply to Robert McQueen [:ramcq] from comment #22)

(In reply to Mike Kaply [:mkaply] from comment #21)

That's odd because the default browser check definitely works via distribution.ini (and has for years).

Exactly! But the prefs.js we removed in https://bugzilla.mozilla.org/show_bug.cgi?id=1795998 also contained a duplicated/redundant preference to remove the browser check, which has now gone.

Sorry this might be noise; I've tested 123 on a new profile and I've observed both the default browser preference (false) and spell checker default path (/usr/share/hunspell) being correctly set according to the distribution.ini - there was no default browser check experienced.

Comment 24

[:gerard-majax]

(In reply to Robert McQueen [:ramcq] from comment #23)

(In reply to Robert McQueen [:ramcq] from comment #22)

(In reply to Mike Kaply [:mkaply] from comment #21)

That's odd because the default browser check definitely works via distribution.ini (and has for years).

Exactly! But the prefs.js we removed in https://bugzilla.mozilla.org/show_bug.cgi?id=1795998 also contained a duplicated/redundant preference to remove the browser check, which has now gone.

Sorry this might be noise; I've tested 123 on a new profile and I've observed both the default browser preference (false) and spell checker default path (/usr/share/hunspell) being correctly set according to the distribution.ini - there was no default browser check experienced.

Could the present issue be related to upgrade then ?

Comment 25

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/a5c1fbe78e43

Comment 26

[Emerson Bernier]

(In reply to :gerard-majax from comment #24)

Could the present issue be related to upgrade then ?

No, even as dict pref is applied in config it still doesn't work whether it's new or old profile. On matrix @bbhtt wrote that they seen it working "sometimes" so it may be a race condition bug somewhere as @mkaply suggested.

Comment 27

[Dianna Smith [:diannaS]]

Comment on attachment 9382499 [details]
Bug 1881830 - Pass DICPATH env var to Flatpak r?mkaply!

Approved for 124.0b5

Comment 28

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/177ffd8d54fc

Comment 29

[Pascal Chevrel:pascalc]

Comment on attachment 9382499 [details]
Bug 1881830 - Pass DICPATH env var to Flatpak r?mkaply!

Approved for our planned dot release, thanks.

Comment 30

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/f046d40050ce