Open Bug 1953829 Opened 7 months ago Updated 5 months ago

Enabling resistFingerprinting causes fcitx's preedit text to duplicate in Google Docs

Categories

(Core :: Privacy: Anti-Tracking, defect, P3)

Firefox 136
defect

Tracking

()

UNCONFIRMED

People

(Reporter: pridefulmizuki, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(2 files)

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

Steps to reproduce:

mozregression bisected the range to between 2024-09-10-09-03-27-mozilla-central and 2024-09-11-09-21-34-mozilla-central.

STR on Fedora 41 KDE:

  • Install Fcitx5 and an input method - I reproduced with Unikey, then enable it.
  • Create a fresh profile, enable privacy.resistFIngerprinting and navigate to Google Docs.
  • Type "iii" in the new documents UI so that the preedit text underline show up and then either press space, or click the mouse outside so the text field is no longer in focus.

Actual results:

"iii iii "

Expected results:

"iii "

Attached image before pressing space โ€”
Attached image after pressing space โ€”

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

Component: Untriaged → Privacy: Anti-Tracking
Product: Firefox → Core

Now that is unusual.. Thank you very much for the pushlog although unfortunately nothing jumps out to me in it.

For reference on this date I found the pushlogs about https://hg.mozilla.org/mozilla-central/pushloghtml/50

Since you were able to use Mozregression, do you think you could try testing the individual RFPTargets with our debugging extension? You would:

  1. Install the extension
  2. Disable RFP
  3. Enable privacy.fingerprintingProtection
  4. Choose the troubleshoot Website feature in the extension button
  5. Confirm the issue reproduces
  6. Mark it as such in the extension
  7. The extension will then disable and enable sets of RFPTargets and you attempt to reproduce the issue after every time you report the outcome to the extension. (You should reload the page after every time, to be safe.)

If it works, you will be able to see which RFPTarget specifically is causing the behavior which will really help with narrowing it down.

I actually am not able to reproduce at all with RFP off, even after using the troubleshoot website option and enabling all RFPTargets. Turning RFP on again and the problem immediately reappears.

(I did enable FPP, afraid it wasn't clear)
Also, mozregression did offer to bisect the commits in that day, because it seems the date is recent enough for there to be builds-per-commit available. However Firefox fails to load the IMEs with some glib error (this is with ibus, but fcitx failed also) so I was only able to narrow the date.

2025-03-15T17:16:59.894000: INFO : b'(firefox-nightly:7658): Gtk-WARNING **: 17:16:59.887: /lib/x86_64-linux-gnu/libibus-1.0.so.5: undefined symbol: g_task_set_static_name'
2025-03-15T17:16:59.894000: INFO : b"[Parent 7658, Main Thread] WARNING: Loading IM context type 'ibus' failed: 'glib warning', file /builds/worker/checkouts/gecko/toolkit/xre/nsSigHandlers.cpp:187"
2025-03-15T17:16:59.894000: INFO : b''
2025-03-15T17:16:59.894000: INFO : b"(firefox-nightly:7658): Gtk-WARNING **: 17:16:59.887: Loading IM context type 'ibus' failed"
Severity: -- → S3
Priority: -- → P3

I would like to say I have found the responsible commit by bisecting local builds: https://hg-edge.mozilla.org/mozilla-central/rev/75db5798bdd41e93cc1e537eabfc25b13b83bec4

Keywords: regression
Regressed by: 1826051

:fkilic, since you are the author of the regressor, bug 1826051, could you take a look?

For more information, please visit BugBot documentation.

Flags: needinfo?(fkilic)

This is really interesting. I can't really tell what would cause this. That patch is about pointer events. AFAICT we also dont do RFP only pointer spoofing. Just to make sure, can you try the following two configs and report back whether the bug reproduces or not?

  • privacy.fingerprintingProtection = True
  • privacy.fingerprintingProtection.overrides = +AllTargets
  • privacy.fingerprintingProtection = True
  • privacy.fingerprintingProtection.overrides = -AllTargets,+PointerId,+PointerEvents

(with 1, I'm trying to understand if there's some RFP only protection that I'm missing, and with 2, I'm trying to make sure it is about pointer spoofing)

Also, if you don't mind, if you can reproduce the bug with 2, can you also remove one of the PointerId or PointerEvents to see which one is affecting it? So it would be something like

a)

  • privacy.fingerprintingProtection = True
  • privacy.fingerprintingProtection.overrides = -AllTargets,+PointerId

b)

  • privacy.fingerprintingProtection = True
  • privacy.fingerprintingProtection.overrides = -AllTargets,+PointerEvents
Flags: needinfo?(fkilic)

I can reproduce with -AllTargets,+PointerEvents

Hmm okay so it isn't RFP only. I'm still not sure what can cause this though. With PointerEvents (1, 2) we spoof

  • PointerType
  • PointerId
  • Width
  • Height
  • Pressure
  • TangentialPressure
  • TiltX
  • TiltY
  • Twist
  • AltitudeAngle
  • AzimuthAngle
  • MaxTouchPoints
  • MozPressure
  • InputSource
  • CheckPointerCaptureState.

I can't tell which one would be responsible for it. You are also saying it happens when you press space key too, which is even more weird.

Actually I just checked it again, it's not just the space key but it occurs with pretty much any key and any pointer event pressed after that causes the preedit text field to stop registering more keypresses.
So if I type any alphanumerical key (A-Z0-9), that counts as the characters that the IME will store in the buffer and it will simply add that character normally. But if I type any other key (Tab, F5, ", +, \ etc) or does any mouse click, that forces that buffer to be "processed", it occurs.

Example:
abcd1234: normal
abcd1234- : duplicated

Of the things we spoof I mentioned in comment 11, I'm not sure which one would cause this unfortunately.

Is there a way to even more granularly control which PointerEvent thing we spoof? Even if it require a custom build?

also see https://support.google.com/docs/thread/197176873/some-keystrokes-generate-two-characters-in-google-docs-and-google-slides-but-not-anywhere-else?hl=en - user is gecko with RFP enabled

edit: in this case the user had webGL disabled, enabled it, problem was fixed

user is gecko with RFP enabled

When they said

disabling all add-ons and extensions, hardware acceleration, and basically any security settings, yet this issue still persisted

I wonder if they also disabled RFP.

Is there a way to even more granularly control which PointerEvent thing we spoof? Even if it require a custom build?

I mean, we can replace if (ShouldResistFingerprinting(RFPTarget::PointerEvents)) with if (false) one by one and see which of them fixes it. I don't have a lot of space on my machine right now (not enough to spin up a fedora vm and build firefox at least). I can't replicate on my machine either (it doesn't happen with RFP or PointerEvents only, and fcitx isn't available on osx)

edit: in this case the user had webGL disabled, enabled it, problem was fixed

Is this also the case for you Mizuki Nguyen?

I mean, we can replace if (ShouldResistFingerprinting(RFPTarget::PointerEvents)) with if (false) one by one and see which of them fixes it. I don't have a lot of space on my machine right now (not enough to spin up a fedora vm and build firefox at least). I can't replicate on my machine either (it doesn't happen with RFP or PointerEvents only, and fcitx isn't available on osx)

I'd be willing to do that. Also, I can replicate it in Mint + IBus, so I think this is a general Linux IME issue. I think any IME that support application-embedded preedit would be affected by this.

Is this also the case for you Mizuki Nguyen?

No, WebGL is enabled for me.

There are three of these

if (aCallerType != CallerType::System && nsContentUtils::ShouldResistFingerprinting(GetDocShell(), RFPTarget::PointerEvents))

for MaxTouchPoints, InputSource and MozPressure, and I just need to change them to if (false) one by one correct?

Yes correct. Here you can find all the spots it is used, and replace them with false as you mentioned.

I'd like to say disabling maxTouchPoints spoofing fixes it for me.

Hmm, this function is called by other stuff too. so if changing every if ShouldRFP(PointerEvents) to false doesn't fix it, you may also try changing these to false.

(In reply to Mizuki Nguyen from comment #20)

I'd like to say disabling maxTouchPoints spoofing fixes it for me.

Max touch points? I wonder how that affects text duplicating. Once I'm done with all the Android patches (and delete my android build), I'll try to install a linux vm and try to solve this bug.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: