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?
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
Afaik Firefox has nothing to do with your compose key input. Are you sure this is happening only in Firefox? Of so an explanation might be that you have a font rendering issue, and the symbol the compose key produces is different in your system font compared to the font Firefox uses? Can’t really explain how you’d get different symbols in apps otherwise.
gtk is handling compose in the case of firefox. The onus is on the application to implement compose, which here firefox does through gtk. It is working correctly in modt programs but not in gtk ones, they have the same issues. It is also most definitely unrelated to the font, the behavior doesn’t match either, not just the looks.
As described in the other comments, I have managed to add the missing compose sequences by prepending the regular compose default file to the userdefined .XCompose and putting that into the gtk specific compose file .config/gtk-{2,3,4}.0/Compose
You got different compose sequences otherwise because gtk has weird ones baked in and refuses to read the correct ones from the proper files
