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?

  • yoasif@fedia.ioM
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    1 year ago

    While I am not entirely sure of what you are talking about, it sounds like you are trying to define shortcuts or overrides in X11/Xorg input settings for your input device. My guess is, based on the age of the Firefox port on *nix, and the fact that X is basically dead upstream - is that even if this is a valid bug, you probably won’t get a fix very quickly.

    Why? It isn’t Wayland and I’m guessing the abstractions here are cleaner.

    If you want to report the bug that you are experiencing, I would report into the Gtk component: https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Widget%3A%20Gtk