Open Bug 1754683 Opened 2 years ago Updated 10 months ago

Character input with Japanese IM can not be done onto new folder dialog on Thunderbird for macOS.

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
Unspecified
macOS
Type:
defect

Tracking

()

Status:
REOPENED

People

(Reporter: shiggy_g, Unassigned)

References

Details

(Keywords: inputmethod)

Attachments

(4 files)

log_file
.moz_log
88.64 KB, text/plain
Details
log_file
.child-1.moz_log
69 bytes, application/octet-stream
Details
Daily_2023-07-01_log_file.moz_log
39.90 KB, text/plain
Details
No1754683_Bug.mov
7.80 MB, video/quicktime
Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

Platform:
MacBook Pro　13-inch 2020 Intel
macOS Monterey 12.2
Japanese IM OS Standard
Thunderbird 91.6.0 64Bit

Reproduce: 100%

Steps to reproduce:

1 Start Thunderbird.
2 Input password (if needed).
3 Open new folder dialog.
4 Hit keyboard for folder name.
5 Any characters never appear (actual result).
6 Change the focus to other point.
7 Then return focus into input area on the new folder dialog again.
8 Hit keyboard for folder name again.
9 The characters appear on new folder name area correctly (expected result at step 5).
10 This phenomenon occurs every time when new folder dialog started.
That means repeating from step 3 to step 9 must be done.

Actual results:

Please refer step 5

Information I tried:
This phenomenon on macOS Big Sur was observed as well.
It happens by input with US IM macOS standard.
For making sure input from hitting key is correct or not, monitoring with keyboard viewer and key responds correctly.
This can not be resolved by starting in safe mode or new profile.

Expected results:

Please refer step 9

I have corrections.

Firstly,
This phenomenon happens ONLY on Japanese IM macOS Standard.
Making clear this, I made small change about summary.

Correction in steps for reproduce:
Description: Step 2 Input password (if needed).
Please ignore this step 2 because this step was not affect to this phenomenon.

Correction in information I tried:
Description: It happens by input with US IM macOS standard.
I would like to withdrawn this item because US IM was working correctly.
It was my mistake.

Summary: Character input can not be done onto new folder dialog on Thunderbird for macOS. → Character input with Japanese IM can not be done onto new folder dialog on Thunderbird for macOS.

This bug was discussed on the MozillaZine.jp forum and then reported here.
I have heard about the situation from the reporter and would like to make some additional comments.

  • The second step to reproduce, but this is not necessary as it does not affect the results.
  • This issue occurs when typing a name in Japanese as soon as the "New Folder" dialog is displayed.
  • The following is a mistake.

    It happens by input with US IM macOS standard.

  • This issue only occurs on Mac and not on Windows.
  • Another Mac user reported that it also happens when typing a name in the "Filter Rules" dialog.

Additional Information:
After update Thunderbird to new release, and it reboot automatically.
New folder name can input correctly in this condition only.
But once quit Thunderbird application after update, and start it again, the phenomenon still remain.

The organized steps just after new release Thunderbird to check the phenomenon additionally previous report.

1 Notice for update from Thunderbird appears.
2 Start update for new release.
3 New Thunderbird application restarts automatically.
4 Start for creating new folder name dialog.
5 Input new folder name on it.
6 Characters appear on the name area correctly.
7 Close the new folder name dialog.
9 Then start for creating new folder name dialog again.
10 Input new folder name on it.
11 Characters never appear on the name area.

Mac OS 12.6
Thunderbird 102.3.3 (64 ビット)

The related MozillaZine.jp topic has been updated, so I came here to see what is going on.

(In reply to Shiggy from comment #4)

The organized steps just after new release Thunderbird to check the phenomenon additionally previous report.

Siggy.
I don't think it is necessary to explain the steps to reproduce it, since it is not the essence of the problem.

Mac OS 12.6
Thunderbird 102.3.3 (64 ビット)

So you are reporting that this also occurred with Mac OS 12.6 + Thunderbird 102.3.3 (64 bit).

I'll try to reiterate the points of this bug.

  • This bug occurs when Mac users type Japanese in the "New Folder" dialog of Thunderbird.
  • It occurs only on Mac, not on Windows.
  • Some users report that it also occurs in the "Filter Rules" dialog.
  • It has been reported that this bug can be avoided by moving the focus once to another part of the screen when typing Japanese.

Masayuki-san, any idea what is going on here?

Flags: needinfo?(masayuki)

Odd, I don't reproduce this bug within today's Daily in macOS Ventura 13.4.

Flags: needinfo?(masayuki)

I'd like to check the main process's log of IMEHandler:4,ContentCacheWidgets:4,IMEStateManager:4,IMEContentObserver:4,sync from focusing a password field getting focus and to focusing a new folder dialog's editor. I think that you need to run Thunderbird from the terminal with setting MOZ_LOG to them and setting MOZ_LOG_FILE too.

Note that be careful about the log not containing your privacy especially including the password. The log stores all typed text and may contain editor values. Therefore, I strongly recommend that you should cancel the password prompt without typing/pasting anything.

Dear Nakano-san,

My concerns are:
I'm not familiar with terminal application.

  1. I will execute bellow on Terminal application.
    And reproduce issue with Thunderbird that I reported from step 1 to step 9 on the first report from me.
    At step 2, password dialog is canceled without any input.
    Is this procedure good for your request?

#!/bin/sh
export MOZ_LOG=IMEHandler:4,ContentCacheWidgets:4,IMEStateManager:4,IMEContentObserver:4,sync
export MOZ_LOG_FILE=$HOME/Desktop/log_file
/Applications/Thunderbird.app/Contents/MacOS/thunderbird-bin &

  1. Does log store personal or/and security information except you mentioned?
    Because I will try with my personal mail account.

  2. How can I check information in log file?

EarlgreyTea-san, Thank you for support.

Sorry, Correction.
Concern Item 3:
This means check for word that I care and it's not analysis.

Attached file log_file
.moz_log —

Nakano-san
EarlgreyTea-san resolve my concerns.
And I got 2 logs.
Could you please check them?
Thank you.

Nakano-san.
For your reference.(related to my comment 1)
This issue can reproduce only below setting by Text Input:
Input source : Japanese-Roman letters

I guess reason that you could not reproduce for setting with US.
How do you think?

Attachment #9340801 - Attachment mime type: application/octet-stream → text/plain

(In reply to Shiggy from comment #13)

And I got 2 logs.

First one is the log in the main process which has the native IME handler and chrome UI, the other is a content process (I don't know for what).

Indeed, while keyDown: of a is handled in cocoa widgets, composition didn't start.

(In reply to Shiggy from comment #14)

This issue can reproduce only below setting by Text Input:
Input source : Japanese-Roman letters

I guess reason that you could not reproduce for setting with US.
How do you think?

I'm not sure, I tried to reproduce this with both Apple's IME and ATOK, but I couldn't reproduce this.

Unfortunately, I don't get any guesses from the log. Looks like that at least, the cross platform part works as expected. So I think that a bug is in the native IME handler in the cocoa widget.

Can you (or somebody who can reproduce this) try to check it with Thunderbird Daily (equivalent to Firefox Nightly)? I recommend to do it with VM or something which guarantees that Daily won't touch your default profile. I'll add more things to the logging code, but nobody can check it in Daily, we need to wait next ESR (next of 115).

Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → macOS

Oh, I realized that according to the log (attachment 9340801 [details]), you didn't re-enable the IME's composition mode (i.e., com.apple.inputmethod.Kotoeri.RomajiTyping.Japanese). Did you change IME mode after the password editor lost focus, but it's not correctly logged?

Flags: needinfo?(shiggy_g)

Additionally, can you reproduce it with Firefox? Here is a test page which shows Basic Auth dialog (type test/test for user and password):
https://d-toybox.com/test/input-autofocus.html

I tried to check it in Thunderbird 102.12.0 in macOS Ventura 13.4, but I still cannot reproduce this bug.

Reply to Comment #15
I'm not sure about Thunderbird Daily or something.
If something I can, could you please show me precise procedure or steps?

Reply to Comment #16
After closed password dialog by clicking cancel button,
I opened new folder dialog according with reported reproduce step with mouse.
Nothing else.

Reply to Comment #17
I tried character input after login.
No problem.
Characters are displayed correctly.

Lastly.
Could you show me different from my comment #3?

Flags: needinfo?(shiggy_g)

(In reply to Shiggy from comment #20)

Reply to Comment #15
I'm not sure about Thunderbird Daily or something.
If something I can, could you please show me precise procedure or steps?

Ah, according to the beta release document, currently the non-release channel builds use its own profile. So, you can test it safer.

You can download Daily builds from here. I'll let you know when new build which can log more data is available.

Reply to Comment #17
I tried character input after login.
No problem.
Characters are displayed correctly.

Thank you. It seems that Firefox completely discarded modal dialogs, so that's why it hard to reproduce in Firefox...

Lastly.
Could you show me different from my comment #3?

Although there is no way to follow the STR with updating Thunderbird, I can use IME even after I open the dialog again both in Thunderbird 102 and Daily.

Thank you.
Please let me know when new release.

Apple original Japanese IME is only installed on my Mac.
Do you think that installed ATOK on your Mac affects to this issue?

One more my concern.
I guess another possibility about result difference may caused by type of processor.
My Mac has Intel Processor.
How about yours?
Intel or M?

Shiggy, I would like to support you, so could you come to the MozillaZine.jp topic ?

(In reply to Shiggy from comment #22)

Thank you.
Please let me know when new release.

July 10

Component: Untriaged → Folder and Message Lists

(In reply to Wayne Mery (:wsmwk) from comment #25)

(In reply to Shiggy from comment #22)

Thank you.
Please let me know when new release.

July 10

No, the question is for what the new Daily build which includes the fix in bug 1840307.

Nakano-san

Sorry for my tardy reply.
I put log for Daily(2023-07-01) as an attachment.
I added Daily Version on log file name.
Could you please check it?
Below is what I have done.

Platform:
MacBook Pro　13-inch 2020 Intel
macOS Ventura 13.4.1
Japanese IM OS Standard
Thunderbird Daily (2023-07-01)

Set to alphabetic (Eiji：英字) input mode on Japanese - Roman Letters input source.

Steps for reproduce:

  1. Start Daily with Terminal application.
  2. Application is changed from Terminal App to Daily App with mouse click.
  3. Move mouse pointer to place where new folder is put in folder pane.
  4. Open new folder dialog by clicking "New Folder.." with right click menu of mouse.
  5. Hit keyboard for folder name. (3 times "a")
  6. Any characters never appear.
  7. Quit Thunderbird Daily by clicking "Quit Daily" under "Thunderbird Daily" on application menu.
  8. Quit Terminal App.

Terminal Commands:
#!/bin/sh
export MOZ_LOG=IMEHandler:4,ContentCacheWidgets:4,IMEStateManager:4,IMEContentObserver:4,sync
export MOZ_LOG_FILE=$HOME/Desktop/log_file
/Applications/"Thunderbird Daily".app/Contents/MacOS/thunderbird-bin &

I scanned the attached file Daily_2023-07-01_log_file.moz_log and found only one of the logs added by bug 1840307.

Line208:

[Parent 2476: Main Thread]: D/IMEHandler 14d413230 IMEInputHandler::NotifyIME(), IsFocused()=true, widget=148f8b700, IsPasswordEditor()=FALSE
Flags: needinfo?(masayuki)
Attachment #9342186 - Attachment mime type: application/octet-stream → text/plain
Flags: needinfo?(masayuki)

Sorry for the long delay due to struggling with regressions which should be fixed before the merge.

(In reply to Shiggy from comment #22)

Apple original Japanese IME is only installed on my Mac.
Do you think that installed ATOK on your Mac affects to this issue?

I think that it should not occur. IIRC, each IME works as independent process.

(In reply to Shiggy from comment #23)

I guess another possibility about result difference may caused by type of processor.
My Mac has Intel Processor.

Me too. I'm using Intel Mac mini.

Thank you for the new log!

(In reply to Shiggy from comment #28)

Steps for reproduce:

  1. Start Daily with Terminal application.
  2. Application is changed from Terminal App to Daily App with mouse click.
  3. Move mouse pointer to place where new folder is put in folder pane.
  4. Open new folder dialog by clicking "New Folder.." with right click menu of mouse.
  5. Hit keyboard for folder name. (3 times "a")
  6. Any characters never appear.
  7. Quit Thunderbird Daily by clicking "Quit Daily" under "Thunderbird Daily" on application menu.
  8. Quit Terminal App.

Oh!? It's reproducible without password editor... Hmm...

IMEInputHandler::NotifyIME(), IsFocused()=true, widget=148f8b700, IsPasswordEditor()=FALSE

When Gecko notifies IMEHandler of focus, cocoa widget correctly has focus...

IME has already enabled by IMEStateManager on the widget before the line, here:

IMEStateManager SetInputContext(aWidget=0x148f8b700, aInputContext={ mIMEState={ mEnabled=ENABLED, mOpen=DONT_CHANGE_OPEN_STATE }, mOrigin=ORIGIN_MAIN, mHTMLInputType="text", mHTMLInputMode="", mActionHint="", mAutocapitalize="", mIsPrivateBrowsing=false }, aAction={ mCause=CAUSE_UNKNOWN_CHROME, mAction=GOT_FOCUS }), BrowserParent::GetFocused()=0x0

Then, you press a:

TextInputHandler::HandleKeyDownEvent, aNativeEvent=148e88e80, type=NSEventTypeKeyDown, keyCode=0 (0x0), modifierFlags=0x100, characters="a", charactersIgnoringModifiers="a"

and it correctly sends the keydown event to IME via cocoa API:

TextInputHandler::HandleKeyDownEvent, calling interpretKeyEvents

Then, IME requests selected range and we returned it without any error:

IMEInputHandler::SelectedRange, querySelectedTextEvent={ mReply={ mOffsetAndData={ mOffset=0, mData="" (Length()=0), Length()=0, EndOffset()=0 }, , mWritingMode=h-ltr, mContentsRoot=0x0x13aae8280, mIsEditableContent=true, mFocusedWidget=0x0x0 } }

Finally, the cocoa widget returned from the API call without starting composition:

TextInputHandler::HandleKeyDownEvent, called interpretKeyEvents

Hmm. Do we fail to enable IME in this case? I'll check it.

We manage IME enabled state in macOS and we choose whether to call the API or not with the flag. Therefore, we succeeded to enable IME since the API is called in the log.

Any characters never appear.

I wonder, this is completely odd. Even if IME is not available, insertText: should be called instead of setMarkrdText:. So, something has not been prepared yet for accepting keyboard input...

Shiggy-san, do you see something in the system log when you fail to input text? (I hope IME or cocoa leaves something for the unexpected situation. So it's fine to check it in normal release build without logging of Thunderbird.)

Flags: needinfo?(shiggy_g)

(In reply to Nakano-san from comment #32)

Nakano-san,
I checked System Log of Mac after character input error with Thunderbird Release(102.12.0).
Nothing added is found on the list by checking timestamp.

By the way,
I saw strange phenomenon when I tried to get Log for Daily(2023--7-01) with Terminal App.
I tried at least 3 times to get log for bug report.
One of them, in case of skipped Step 2,
New Folder Dialog open ordinary at Step 4 after Step 3,
input characters were displayed on Terminal App instead of New Folder Dialog at Step 5.
This means Step 1,3,4,5 of reproduce steps simply. (not for bug report)
How do you think this behavior?

Flags: needinfo?(shiggy_g)

That sounds like Gecko fails to manage focus in OS level (e.g., notifying the focus manager of Cocoa). And yeah, I managed reproduce this bug with this steps:

  1. Open Firefox and Thunderbird
  2. Make the search field in Firefox focused
  3. Right click on Thunderbird's folder pane to show the context menu (without activating Thunderbird)
  4. Click "New Subfolder..."
  5. Type text with IME

Then, I see text in the search bar of Firefox. And the menubar says Firefox is still active, however, Thunderbird's new folder dialog looks active. So I think that this is a bug of Gecko. How about the active application when you reproduced this bug?

Component: Folder and Message Lists → DOM: UI Events & Focus Handling
Flags: needinfo?(shiggy_g)
Product: Thunderbird → Core
Version: Thunderbird 91 → unspecified

Okay, I see same symptom with "Add Bookmark..." menu item in the context menu on a bookmark folder in the left pane of Library window.

Hmm, I see same symptom on VSCode with "Spelling Suggestions..." on a misspelled word in the editor. Is this a standard behavior on macOS?

On Safari's bookmark manager, I see similar symptom, but Safari shows it's inactive. So, this could be a bug of UI rendering...

(In reply to Nakano-san from comment #35)

I saw bug that you tried by using Thunderbird Release(102.12.0) and Firefox (114.0.2) with Step 1 to 5 you show.
Input characters are shown in the search bar of Firefox.
Same phenomenon I mentioned in Comment #34.

Status: NEW → RESOLVED
Closed: 10 months ago
Flags: needinfo?(shiggy_g)
Resolution: --- → INVALID

Sorry my mistake.
I'm not sure how I can correct it to normal about below:
Resolution: --- → INVALID

Thank you, but my point is, when you see the symptom in your steps, what application is active in the menubar?

And I think that it's a bug that the <input> in the dialogs shows focus ring as which has keyboard focus in the desktop.

Status: RESOLVED → REOPENED
Flags: needinfo?(shiggy_g)
Resolution: INVALID → ---

(In reply to Nakano-san from comment #41)

In case of bug test by Thunderbird Release(102.12.0) and Firefox (114.0.2) :
Firefox is active in menu bar.
In case of bug test by Daily(2023-07-01) and Terminal App:
Terminal App is active in menu bar.

Flags: needinfo?(shiggy_g)
Severity: -- → S3
Attached video No1754683_Bug.mov —

For your reference:
I put a video reproduced "New Folder" dialog bug on my Mac as an attachment.

On video (No1754683_Bug.mov):
At 28sec, I typed "a" 3 times in 1sec interval.
Input characters were not displayed by bug.

At 39sec, I typed "a" 3 times in 1sec interval again.
Input characters were displayed correctly.

Platform:
MacBook Pro 13-inch 2020 Intel
macOS Ventura 13.4.1
Japanese IM OS Standard
Thunderbird Release 102.12.0 (64bit)

EarlgreyTea-san, Thank you for support.

Thank you for taking a lot of time to check the behavior in your environment.

Indeed, even though the menubar indicates Thunderbird active, but you cannot type text. However, I still don't reproduce it in my environment. I wonder, did you change some accessibility settings in the system settings or did you install some special applications which may affect focus management in OS level or adjusting keyboard input, e.g., special keyboard utility or mouse utility for your equipment?

Another question is here. Don't you never reproduce this bug with the search bar etc which appears in the main window of launched applications, right? If so, it seems that something blocks focus management when a dialog appears from a context menu (content menu is a special window which cannot take focus).

I guess that we should take a look of focus state when keyDown:. I'll file a bug to add logging code for that.

(In reply to Nakano-san from comment #45)

change some accessibility settings in the system settings
About Keyboard:
All functions are "Off"
About Mouse:
I'm using Apple Magic Mouse(1st Generation).
"Pointer Speed ", "Click Interval" and "Scroll Direction" were adjusted.
Other items are nothing changed.

install some special applications which may affect focus management in OS level or adjusting keyboard input
I don't have special utilities or application related to Keyboard or Mouse or Focus.

reproduce this bug with the search bar etc which appears in the main window of launched applications
The bug is reproduced with "New Folder", "Rename" of folder and "Filter Name" dialog on Thunderbird Release.
Each App below, characters typed were displayed correctly immediately after startup.
Firefox 115.0.1 (64 bit)
Microsoft Excel Ver.16.74
Microsoft Word Ver.16.74
Microsoft PowerPoint Ver.16.74
Text Edit Ver.1.18

For your reference:
I updated Thunderbird Release from Version 78 to Version 91 around late September 2021.
I faced this bug when I tried to create a New Folder middle October 2021.
Between before and after of update, environment of Mac was same.

In comment 46,
I made a mistake quotes method.
1st line of each quotation is question from Nakano-san.
Other lines are my answer.

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

Attachment

General

Creator:
Created:
Updated:
Size: