Mozc is disabled on browsers

[Ks4four]

Description

Mozc didn't work on browsers in my system.

Steps to reproduce

Steps to reproduce the behavior:

1. Go to Firefox, Chrome, Etc...
2. Click on any input boxes
3. Type anything

Expected behavior

It should be able to convert or have a suggestion box below my cursor.

Actual behavior

It's unable to reach the IME options, even if it says "Right click to show IME options".
It also failed to suggest and let the text box making direct input.
It can't change to katakana mode, hiragana mode, or direct input... etc.
It seems like it's disabled.

Screenshots

Version or commit-id

Mozc-2.29.5210.100+24.11.oss

Environment

• OS: Windows 10 Pro 22H2, 19045.3393
• Firefox Developer Edition, Chrome, Microsoft Edge

Investigations

• This issue doesn't happen on Google Japanese IME.

• What applications this issue happens on.

  • Firefox Developer Edition (x64 en-US) 118.0
  • Chrome 116.0.5845.180, via Scoop
  • Microsoft Edge 116.0.1938.69

• What applications this issue does not happen on.

  • anything that not a browser by far

• (optional) What versions or commit-ids this issue did not happen on

  • no-investigation

Additional context

Setting region and language to Japan and Japanese doesn't solve the problem.

[yukawa]

Hmm, I cannot reproduce the issue locally. If your issue is specific to web browsers, once thing I suspect is that your environment has some antivirus software that prevents Mozc DLLs (e.g. mozc_tip64.dll) from establishing a named-pipe connection to mozc_server.exe.

If you happen to be familiar with Windows software development, one of the most straightforward ways to figure out what's going on would be debugging the following lines in the browser process (e.g. chrome.exe).

mozc/src/ipc/win32_ipc.cc

Lines 636 to 752 in f79e092

	void IPCClient::Init(const absl::string_view name,
	const absl::string_view server_path) {
	last_ipc_error_ = IPC_NO_CONNECTION;
	// We should change the mutex based on which IPC server we will talk with.
	const wil::unique_mutex_nothrow &ipc_mutex = GetClientMutex(name);
	wil::mutex_release_scope_exit mutex_releaser;
	if (ipc_mutex.get() == nullptr) {
	LOG(ERROR) << "IPC mutex is not available";
	} else {
	constexpr int kMutexTimeout = 10 * 1000; // wait at most 10sec.
	DWORD status;
	mutex_releaser = ipc_mutex.acquire(&status, kMutexTimeout);
	switch (status) {
	case WAIT_TIMEOUT:
	// TODO(taku): with suspend/resume, WaitForSingleObject may
	// return WAIT_TIMEOUT. We have to consider the case
	// in the future.
	LOG(ERROR) << "IPC client was not available even after "
	<< kMutexTimeout << " msec.";
	break;
	case WAIT_ABANDONED:
	DLOG(INFO) << "mutex object was removed";
	break;
	case WAIT_OBJECT_0:
	break;
	default:
	break;
	}
	}
	IPCPathManager *manager = IPCPathManager::GetIPCPathManager(name);
	if (manager == nullptr) {
	LOG(ERROR) << "IPCPathManager::GetIPCPathManager failed";
	return;
	}
	ipc_path_manager_ = manager;
	// TODO(taku): enable them on Mac/Linux
	#ifdef DEBUG
	constexpr size_t kMaxTrial = 256;
	#else // DEBUG
	constexpr size_t kMaxTrial = 2;
	#endif // DEBUG
	for (size_t trial = 0; trial < kMaxTrial; ++trial) {
	std::string server_address;
	if (!manager->LoadPathName() || !manager->GetPathName(&server_address)) {
	continue;
	}
	std::wstring wserver_address = Utf8ToWide(server_address);
	if (GetNumberOfProcessors() == 1) {
	// When the code is running in single processor environment, sometimes
	// IPC server has not finished the clean-up tasks for the previous IPC
	// session here. So we intentionally call WaitNamedPipe API so that IPC
	// server has a chance to complete clean-up tasks if necessary.
	// NOTE: We cannot set 0 for the wait time because 0 has a special meaning
	// as |NMPWAIT_USE_DEFAULT_WAIT|.
	constexpr DWORD kMinWaitTimeForWaitNamedPipe = 1;
	::WaitNamedPipe(wserver_address.c_str(), kMinWaitTimeForWaitNamedPipe);
	}
	wil::unique_hfile new_handle(
	::CreateFile(wserver_address.c_str(), GENERIC_READ | GENERIC_WRITE, 0,
	nullptr, OPEN_EXISTING,
	FILE_FLAG_OVERLAPPED | SECURITY_SQOS_PRESENT |
	SECURITY_IDENTIFICATION | SECURITY_EFFECTIVE_ONLY,
	nullptr));
	const DWORD create_file_error = ::GetLastError();
	if (new_handle) {
	pipe_handle_ = std::move(new_handle);
	MaybeDisableFileCompletionNotification(pipe_handle_.get());
	// Set PIPE_READMODE_MESSAGE so that we can rely on ERROR_MORE_DATA.
	// https://learn.microsoft.com/en-us/windows/win32/ipc/named-pipe-client
	DWORD mode = PIPE_READMODE_MESSAGE;
	::SetNamedPipeHandleState(pipe_handle_.get(), &mode, nullptr, nullptr);
	if (!manager->IsValidServer(GetServerProcessIdImpl(pipe_handle_.get()),
	server_path)) {
	LOG(ERROR) << "Connecting to invalid server";
	last_ipc_error_ = IPC_INVALID_SERVER;
	return;
	}
	last_ipc_error_ = IPC_NO_ERROR;
	connected_ = true;
	return;
	}
	if (ERROR_PIPE_BUSY != create_file_error) {
	LOG(ERROR) << "Server is not running: " << create_file_error;
	manager->Clear();
	continue;
	}
	// wait for 10 second until server is ready
	// TODO(taku): control the timeout via flag.
	#ifdef DEBUG
	constexpr int kNamedPipeTimeout = 100000; // 100 sec
	#else // DEBUG
	constexpr int kNamedPipeTimeout = 10000; // 10 sec
	#endif // DEBUG
	DLOG(ERROR) << "Server is busy. waiting for " << kNamedPipeTimeout
	<< " msec";
	if (!::WaitNamedPipe(wserver_address.c_str(), kNamedPipeTimeout)) {
	const DWORD wait_named_pipe_error = ::GetLastError();
	LOG(ERROR) << "WaitNamedPipe failed: " << wait_named_pipe_error;
	if ((trial + 1) == kMaxTrial) {
	last_ipc_error_ = IPC_TIMEOUT_ERROR;
	return;
	}
	continue; // go 2nd trial
	}
	}
	}

(Another possibility is that mozc_tip64.dll is not loaded at all into the browser process)

[Ks4four]

Thanks for the response and the information about antivirus software.
It is founded that ESET blocking the mozc_tip64.dll for connections, and it works if the Banking & Payment protection was disabled.
I think it's possible to make a whitelist for mozc.