This article intends to explain the technical details between a issue happens when using fcitx5 on Vivaldi. I’m not a Vivaldi user and Vivaldi is not fully open source, so I can’t really comment what change actually caused this, but I’ll just describe my findings. Based on the information from forum post and social network, the issue happens on vivaldi 5.2 but not 5.1.

The Symptom:

https://forum.vivaldi.net/topic/75398/when-closing-one-window-all-other-windows-are-also-closed/48

When open multiple vivaldi windows, and close the vivaldi window afterwards, the whole browser may be closed instead. Only happened when fcitx5 im module is used.

What actually happened?

So first of all, let me talk about some technical details of how fcitx5 im module works: Fcitx 5 im module a plugin to Gtk 3 library used by vivaldi. In the plugin code, it initiates a DBus connection to dbus-daemon, and using dbus to interact with Fcitx 5 server.

Based on some debugging by attach to the relevant vivaldi process, the actual cause of the exiting is the dbus connection being closed. Fcitx 5 im module use gdbus API in gio to get a shared dbus connection (shared means shared within this process) and using it to handle dbus communications. For such shared dbus connection, a property “exit-on-close” is set to true by default. Which means, if the dbus connection is broken, the program will exit. Usually, such things can only happen on system logout when dbus daemon quits.

For some reason, Vivaldi breaks the dbus connection and then triggers the “exit-on-close” behavior defined in gio. I believe there is a bug in Vivaldi browser that caused this. My guess would be Vivaldi wrongly closed a wrong file descriptor which accidentally belongs to the dbus connection, or some weird interaction between glib mainloop within vivaldi, makes dbus connection think it’s closed. Though I don’t have enough evidence for this claim, but for the following reason:

1. No other Gtk application (including chromium/chrome which is what vivaldi based on) suffers from same issue.
2. Vivaldi older version doesn’t have this issue.
3. Even though the gdbus connection is shared, it is only used by fcitx5, otherwise vivaldi will trigger the issue without using fcitx5, but actually not.

I would say the root cause is that there is a bug in Vivaldi code that closes the dbus connection.

Workaround implemented on fcitx5-gtk side (version 5.0.14)

Even though we think the bug is in Vivaldi, we’d like to avoid such issue from happening. So we applied following workaround:

1. Use a private dbus connection object for the fcitx dbus client object. While it would use more resource, but in general it is acceptable. And make sure “exit-on-close” is not set on those private dbus connection objects.
2. Even though we applied (1), we still noticed that dbus connection would be closed by Vivaldi. So we applied workaround (2): always try to recreate the dbus connection object if the original connection is closed.
   The necessity of (2) also confirms our previous guess of root cause, even if the dbus connection object is only owned by fcitx5 im module, somehow the connection will still be closed when Vivaldi window is closed.

Summary

To user who are affected by the issue, you may upgrade to fcitx5-gtk 5.0.14.

While explaining the technical details and debugging experience is fun, I just want to correct some incorrect understanding on this bug:

The root cause of the bug is not in fcitx5-gtk, and the bug is only triggered by fcitx5-gtk. The bug is in Vivaldi and is NOT fixed and the bug itself may have side effect on Vivaldi’s own code. fcitx5-gtk only implements a workaround to this Vivaldi’s bug.

While implementing workaround is not an ideal solution, we still choose to do that because:

1. We want to get the actual problem solved for user.
2. While using a private dbus connection will use a little bit more resource, it may still have some potential benefit from the isolation between the main program that also uses dbus. So workaround part (1) is not entirely a bad idea.

Thank you for your time reading this message.