1796939 - snap-ed firefox doesn't do word break for Thai text

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Ratchanan Srirattanamet]

Attachment: ThWordBreakTest.html

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

Steps to reproduce:

Open a web page with somewhat long Thai sentence in a container, an example of which is attached. Thai words in a sentence doesn't contain whitespaces, and requires some kind of dictionary to do word breaking properly.

Actual results:

The sentence overflows outside of the container.

Expected results:

The sentence is broken at the word boundaries and stays inside the container.

Comment 1

[Ratchanan Srirattanamet]

Attachment: Overflowed Thai sentence on snapped Firefox 106.0.1-1.png

Comment 2

[Ratchanan Srirattanamet]

Attachment: Properly-broken Thai sentence (from snapped Chromium 106.0.5249.119).png

Comment 3

[Ratchanan Srirattanamet]

Additional information:

• This doesn't happen with the distro-agnostic tarball downloaded from www.mozilla.org, so this indicates that it's likely a packaging issue.
• I'm not sure how Firefox do Thai wordbreaks. However, this job is usually done by a library called 'libthai'. Snap-wise, this seems to be part of gnome-3-38-2004 which Firefox snap (and Chromium snap) depend on. Maybe snapped Firefox looks for this library (or its dictionary) in the wrong place?

Comment 4

[Ratchanan Srirattanamet]

Ok. Launching with

LIBTHAI_DICTDIR=/snap/firefox/1993/gnome-platform/usr/share/libthai/ /snap/bin/firefox

fixes word breaking. Which is weird because why in the world does the Chromium snap not require this similar trick? Also, I suspect this to be a common issue...

Comment 5

[Ratchanan Srirattanamet]

Oh, wow. Turns out, gedit snap also has this issue too. So, perhaps this "libthai cannot find its dictionary" is a common thing that maybe should be resolved in gnome-platform itself. But from Firefox snap standpoint, I think you can add

export LIBTHAI_DICTDIR=${SNAP}/gnome-platform/usr/share/libthai/

to the wrapper script, and this issue will be solved. Meanwhile, I'll report this issue to Launchpad, which I hope should have better solution.

Comment 6

[Vee Satayamas]

Firefox 106.0.1 on Flatpak on openSUSE LEAP 15.4 works. So I suppose this issue is specific to the Snap package.

Comment 7

[Vee Satayamas]

(In reply to Ratchanan Srirattanamet from comment #4)

Ok. Launching with

LIBTHAI_DICTDIR=/snap/firefox/1993/gnome-platform/usr/share/libthai/ /snap/bin/firefox

fixes word breaking. Which is weird because why in the world does the Chromium snap not require this similar trick? Also, I suspect this to be a common issue...

Chromium, LibreOffice, etc., break a line using another library, i.e., libicu. So they don't depend on libthai.

Comment 8

[Theppitak Karoonboonyanan]

I don't know how Snap packages are configured, but if LibThai is configured with proper --prefix=..., it's supposed to be able to locate the dictionary without using LIBTHAI_DICTDIR environment.

Comment 9

[wannaphong]

I found the official repository for build the firefox snap. https://github.com/canonical/firefox-snap

Comment 10

[Jonathan Kew [:jfkthame]]

I had a feeling I'd seen a report like this before, but on searching, I think it was the flatpak issue in bug 1630922 that I remembered.

Maybe the comments there might point towards a solution, as I suspect it's a similar issue of configuration/packaging.

Comment 11

[Ratchanan Srirattanamet]

People at the snapcraft forum has found some solution.

https://forum.snapcraft.io/t/thai-word-breaking-doesnt-work-in-snaps-using-common-gnome-snaps-e-g-firefox/32303/4?u=ratchanan.sr

They say the variable can be added in the common launcher script. I think we can wait for that.

Comment 12

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Hello, thank you for the bug report!
I managed to reproduce this issue on:

• Firefox 107.0b7(Snap);
• Firefox 106.0.3(Snap) ;
• Firefox 108.0a1(Snap);
• Firefox 102.4.0esr(Snap);

Tested on Ubuntu 22 with the testcase from Comment 0. Only reproducible on Snap builds.
Setting as NEW.

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to Ratchanan Srirattanamet from comment #5)

Meanwhile, I'll report this issue to Launchpad, which I hope should have better solution.

Would you mind sharing the launchpad bug report, if you ended up reporting this there?

I believe most of the snap-specific Firefox work (particularly relating to external libraries) would happen there instead of here, particularly given that (as you observed) multiple applications are affected by this issue.

Comment 14

[Ratchanan Srirattanamet]

(In reply to Daniel Holbert [:dholbert] from comment #13)

(In reply to Ratchanan Srirattanamet from comment #5)

Meanwhile, I'll report this issue to Launchpad, which I hope should have better solution.

Would you mind sharing the launchpad bug report, if you ended up reporting this there?

Ok. So I ended up not reporting issue this issue to Launchpad, but to Snapcraft forum instead. There's a positive comment already (see comment #11), so I think another report to Launchpad would be redundant - or so I thought. :)

Comment 15

[Daniel Holbert [:dholbert]]

Thanks! I don't know much about the snap ecosystem, but I agree -- it sounds like ogra and kenvandine over there might be in a position to fix this, per https://forum.snapcraft.io/t/thai-word-breaking-doesnt-work-in-snaps-using-common-gnome-snaps-e-g-firefox/32303/4

Comment 16

[:gerard-majax]

Looks like a PR was sent: https://github.com/canonical/firefox-snap/pull/9

Comment 17

[:gerard-majax]

this has been merged upstream and will make it soon to users

Comment 18

[Ryan VanderMeulen [:RyanVM]]

Will future snaps across all channels pick up this change automatically?

Comment 19

[:gerard-majax]

Good question. The fix applies to gnome-platform but I dont know how it ships. Likely sebastian or amin would know?

Comment 20

[seb128]

Yes, next builds will have the fix included. The snapcraft version including the fix is in stable now and I verified today on the edge channel that it's working.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

Sounds good, thanks for confirming!