this post was submitted on 20 Jul 2023
1 points (100.0% liked)

Firefox

77 readers
99 users here now

The latest news and developments on Firefox and Mozilla, a global non-profit that strives to promote openness, innovation and opportunity on the web.

You can subscribe to this community from any Kbin or Lemmy instance:

Related

Rules

While we are not an official Mozilla community, we have adopted the Mozilla Community Participation Guidelines as far as it can be applied to a bin.

Rules

  1. Always be civil and respectful
    Don't be toxic, hostile, or a troll, especially towards Mozilla employees. This includes gratuitous use of profanity.

  2. Don't be a bigot
    No form of bigotry will be tolerated.

  3. Don't post security compromising suggestions
    If you do, include an obvious and clear warning.

  4. Don't post conspiracy theories
    Especially ones about nefarious intentions or funding. If you're concerned: Ask. Please don’t fuel conspiracy thinking here. Don’t try to spread FUD, especially against reliable privacy-enhancing software. Extraordinary claims require extraordinary evidence. Show credible sources.

  5. Don't accuse others of shilling
    Send honest concerns to the moderators and/or admins, and we will investigate.

  6. Do not remove your help posts after they receive replies
    Half the point of asking questions in a public sub is so that everyone can benefit from the answers—which is impossible if you go deleting everything behind yourself once you've gotten yours.

founded 2 years ago
MODERATORS
 

For those who don't know,
The Multi Key is a key you can set on linux, with which you can type an insane amount of unicode characters. It is commonly bound to scroll lock, I will represent it with ↓ here.

A few examples of shortcuts would be
↓TM → ™
↓|v → ↓ (the character I am using here)
↓+- → ±
↓co → ǒ

Now, most of those work just fine in Firefox, but weirdly there are some that don't. For example ↓PP produces ¶ just fine, but ↓RR doesn't type ℝ. for ↓RR the Multi Key input stops, like it does once no more valid sequences are left that match the current input. ↓CC also doesn't type ℂ, but it doesn't stop but continue on as if there was a different sequence starting with CC. I don't see anything special about the sequences that don't work compared to the majority that do.

After some trial an error, I think what is happening is that firefox does read my .XCompose, but the line include "%L", that is supposed to load the default Compose file located in /usr/share/X11/locale/en_US.UTF-8/Compose is ignored. It is not a language configuration error, as include "/usr/share/X11/locale/en_US.UTF-8/Compose" is ignored too. Entering some deliberate modifications or even removing existing sequences from the Compose file doesn't affect Firefox.
I even found some sequence ↓a_ which is supposed to yield ā but firefox has as ª (not to be confused with ᵃ the superscript a) instead.

Searching for the place Firefox' Compose is defined, I grepped for "ª" which is a pretty rare character, and hit libxul.so. I tried a bunch of other characters and found pretty much everything that has a compose sequence is found in that file.

So thus my question would be: Are Firefoxes default compose sequences statically compiled into libxul.so? And if so, why?

"Solution":
GTK has weird compose sequences baked in and refuses to read the correct locale default ones from the proper files, only reading the userdefined file. The only option is to override this by adding the default locale file to the userconfig. A sane way to do this while keeping .XCompose small is described below.

you are viewing a single comment's thread
view the rest of the comments
[–] Redjard 1 points 2 years ago

Looking into the documentation it seems the Compose sequences are hard coded into gtk more or less. GTK cooks up its own compose file locations

To get Compose to work with GTK, add the following line to .profile:

export GTK_IM_MODULE=gtk-im-context-simple

Regarding gtk-im-context-simple, Jens Mühlenhoff notes (1, 2):

In the API documentation:

GtkIMContextSimple reads additional compose sequences from the first of the following files that is found:

  • ~/.config/gtk-3.0/Compose
  • ~/.XCompose, /usr/share/X11/locale/$locale/Compose (for locales that have a nontrivial Compose file)

So the gtk-im-context-simple method has a built-in table and it loads compose sequences from several additional locations. That means it could possible load shorter sequences that you don't expect.

(https://askubuntu.com/questions/1037597/custom-composekey-sequences-in-18-04)

I haven't seen GTK_IM_MODULE=gtk-im-context-simple do anything yet, but other than that firefox' behavior seems to be consistent with this. I think my fix will be to generate .config/gtk-3.0/Compose automatically and leave my .XCompose as-is. Doesn't seem like gtk is interested in stopping to cook their own weird soup on this matter, when they specifically skip "/usr/share/X11/locale/$locale/Compose" for locales they think they know