Duplicate Text Entry When Using AppSheet on Mac

When using AppSheet on a Mac, I experience an issue where, after entering text in a form and pressing Enter, the text I typed is duplicated.

For example, if I type "Hello" and press Enter, it appears as "HelloHello."

Could this be a bug?

โ€ปThis issue occurs specifically when entering text in Japanese. When using English, the problem does not happen.

3 23 1,535
23 REPLIES 23

I use Mac and have never seen that problem.

The machine you are running on should not be an issue.  These are web apps, designed to run inside of a browser.   Try running the app in a different browser on the same Mac.  I suspect you will get the same behavior.  If not, then clear the cache of the first browser and try again.

I suspect though that there is something within your implementation causing this problem. 


- Do you have an Initial Value expression inserted?  If so can you show that?

- Do you have an action attached to the Form Save behavior?  If so, please show that.

- Any Bots touching the row after the Save?  If so, please show.

Thank you for your response.

I have checked the settings, and there are no Initial Value expressions or any custom Form Save behaviors configured. Additionally, there are no Bots interacting with the row after saving.

It seems that this issue only occurs when inputting text in Japanese. When using English, the problem does not happen.

Please contact AppSheet Support for help with this.

Attn @Koichi_Tsuji @takuya_miyai 

I reported this issue to AppSheet Support on June 27th and exchanged 11 emails until September 17th. I received 7 responses from the Support team, but almost all of them were template replies. Throughout this period, I have not received any progress updates or latest information from either the development team or the support team. When I inquired about whether the issue had been successfully reproduced and the timeline for bug resolution, I only received template responses.

While this issue might seem minor or negligible from a global perspective, it has a significant impact on Japanese-speaking macOS users, preventing them from creating applications and conducting actual business operations using AppSheet.

I urgently request a resolution to this issue.

Below, I have detailed the information I reported to the Support team. If anyone is reading this post, I hope it will prompt some action.

Subject:
Bug Related to Japanese Text Conversion

Issue:
A bug has occurred regarding Japanese text conversion. I will provide a specific example in the following images.

Japanese input tools have a character conversion function. When inputting Japanese, this character conversion is always performed.In Japanese, conversion candidates are displayed at word breaks.

image-01:
image-01.png

In image-01, the word is divided into parts 1 and 2. Therefore, character conversion can be performed for both 1 and 2 separately. The word in the image (consisting of 5 kanji characters) is correct, so there's no need to convert either 1 or 2. In such cases, we skip the character conversion and confirm by pressing the Enter key.

image-02:
image-02.png

As described above, when confirming with the Enter key while conversion candidates remain, a bug occurs as shown in image-02. The unconverted word, part 2, is duplicated in the input.This phenomenon has been occurring since around June 25, 2024.

After careful consideration and further testing, I have reason to believe that this problem is indeed related to AppSheet, specifically its interaction with Chrome on MacOS. Please allow me to provide more detailed information:

  1. The issue occurs exclusively when using AppSheet with Chrome on MacOS. It affects both the app editor and desktop mode.
  2. The problem does not occur when using AppSheet with Safari on the same MacOS system.
  3. I have tested with two different Japanese input tools: the standard MacOS Japanese input system and ATOK. The issue is reproducible with both input systems when using Chrome with AppSheet, but not when using Safari.
  4. Since the problem does not occur in Safari, it suggests that the Japanese input systems themselves are not the root cause. The issue only manifests when using AppSheet with Chrome on MacOS.

Given these observations, I believe the issue likely stems from a compatibility problem between AppSheet and the Chrome browser on MacOS, rather than with the Japanese input tools themselves.

Steps to Reproduce the Bug:

  1. In the [Text] field, enter Japanese text consisting of two or more word segments ( image-03 ).
  2. Press the Enter key to confirm the input. Observe that the unconverted word is duplicated in the input, demonstrating the bug. ( image-04)

image-03:
image-03.png

image-04:
image-04.png

Example of Text Input and Bug:

  • Input: "ๆฑไบฌ้ƒฝๅคงๅญฆ" (These kanji characters mean "Tokyo city university")
  • Result: "ๆฑไบฌ้ƒฝๅคงๅญฆๅคงๅญฆ"

Detailed input procedure:

  1. Use the Japanese romaji conversion function.
  2. Type "toukyoutodaigaku" on the keyboard.
  3. Press the space key, and it will be converted to "ๆฑไบฌ้ƒฝๅคงๅญฆ".
  4. When you press the Enter key to confirm without further modification, "ๅคงๅญฆ" (university) is duplicated in the input.

Explanation:
"ๆฑไบฌ้ƒฝๅคงๅญฆ" is not a real university name and is not registered in the Japanese dictionary. It consists of two word segments: "ๆฑไบฌ้ƒฝ" (Tokyo city) and "ๅคงๅญฆ" (university). When confirmed with the Enter key, "ๅคงๅญฆ" (university) is duplicated in the input.

Please note that this issue occurs consistently in the described environment but does not happen when using Safari on MacOS or when using AppSheet on other operating systems.

Thank you for the detailed explanation.

It seems that the same issue occurs when using Japanese input on a Mac. Since the problem does not occur in Safari, I will use that as a workaround for now.

Your help has been very much appreciated.

@11198 

Thank you for your response. However, I respectfully request that you remove the "Solved" status from this thread, as this issue remains unresolved. Let me explain why:

  1. While Safari doesn't exhibit this specific text conversion bug, it presents other significant challenges when using AppSheet. Safari often experiences delays in reflecting AppSheet updates, and sometimes updates fail to apply altogether. This makes Safari an unreliable solution for consistent AppSheet development and usage.
  2. It's important to note that historically, AppSheet has focused its development and optimization on Chrome rather than Safari. Chrome is the standard browser for both app developers and users on MacOS when working with AppSheet. Therefore, suggesting Safari as a workaround doesn't address the core issue.
  3. The continued existence of this bug effectively excludes Japanese-speaking MacOS users from utilizing their preferred and recommended browser for AppSheet development. This situation essentially abandons a significant user base who require reliable Japanese text input functionality.

I hope you understand why this issue should remain open until a proper solution is implemented for Chrome, which is AppSheet's primary supported browser on MacOS.

I understand the importance of the issue.

I will remove the "solved" status.

Since I am a Windows user, I might not notice when the problem is resolved. Therefore, I would appreciate it if you could let me know when the issue is fixed so I can mark it as solved.

Thank you.

@11198 

Thank you for understanding and removing the "solved" status. I truly appreciate your thoughtful response.

When they encounter this text input problem in their first experience with AppSheet, they are likely to abandon the platform immediately, missing out on its powerful capabilities. That's why keeping this thread open and visible is so important.

I will definitely update this thread when the issue is resolved.

Thank you again for your cooperation in maintaining visibility on this issue.

@devingu  @AleksiAlkio  @lizlynch 


@AppliSuite wrote:

This situation essentially abandons a significant user base who require reliable Japanese text input functionality.


You are absolutely right.
Neglecting this issue is definitely a negative for Google.

 

I am Japanese.
I am not a Mac user, so I have not actually experienced this, but I have seen this phenomenon posted in a number of X (formerly Twitter) posts.
I also found a video showing this phenomenon and will post it here.

https://youtu.be/HEz8g9toF4Y?si=iiDNbNYzpmphdW0f&t=1035

Thank you, as always, for your comments.

Iโ€™ve also seen posts about this issue on X a few times.

I appreciate you sharing the video as well.

I am also a MAC user and I use AppSheet in Japanese.
I have been aware of this issue for several months, but it has not been resolved yet.

This issue does not occur when using AppSheet in English.
However, since most of the values I enter in the app are in Japanese, I cannot ignore this bug. This is because if duplicate entries continue to occur when entering values, it will take time and effort to correct them, which is stressful.

I have seen a response before stating that this is not an AppSheet issue, but I believe that this is not OS-dependent. Please consider fixing this. Thank you.

I'm experiencing the same problem.
Even though we've developed it, it's very difficult to use, and we have to ask our clients to use Firefox, Safari, or Edge instead of Chrome, which is a real pain.
It's so difficult that I think it would be better to implement it using Google Forms. (We're actually considering this on the client side.)
I think it's a big minus for Google, which wants to expand Chrome in the future.
Maybe there's no benefit to improving the convenience for Japanese users because the development team is divided and not involved in the evaluation...

Hi @devingu @AleksiAlkio @lizlynch

I have conducted additional investigation into this issue and would like to share some important findings that might help identify the root cause.

Detailed Reproduction Conditions

The text duplication issue shows a clear pattern:

  • Occurs with Text type (and Text-based types like Address, Email)
  • Does NOT occur with LongText type

Technical Analysis

HTML Rendering Differences

Since AppSheet is a web application, I believe the following implementation details are relevant:

  1. LongText Fields
    • Likely implemented using `<textarea>` elements
    • These typically handle input events differently and don't exhibit this duplication behavior
  2. Text Fields
    • Likely implemented using `<input type="text">` elements
    • These might be experiencing issues with Japanese IME (Input Method Editor) event handling

Potential Connection to Recent Updates

Interestingly, there was a localization update around June 20, 2024, specifically for iOS date displays:

Before/After Changes:

  • Before: `Dec 10, 2024`
  • After: `2024/12/20`

This update is notable for several reasons:

  1. User Experience Improvement
    • The change was welcomed by Japanese users
    • The new format aligns better with Japanese date conventions
  2. Technical Implications
    • Date inputs are typically implemented using `<input type="date">`
    • The localization changes for date components might have inadvertently affected text input handling

Hypothesis on Root Cause

Based on my analysis, the issue might be occurring due to:

  1. Input Handling Library Issues
    • The library handling text input might not be properly processing Japanese IME events
    • There could be confusion between IME confirmation events and standard keyboard input events
    • This would explain why it only affects single-line text inputs and not text areas
  2. Localization Update Impact
    • The recent date format localization changes might have affected the input handling system
    • The library managing input events might have been modified to accommodate localized date formats
    • This could have introduced unintended side effects in text input processing

Suggestions for Future Improvements

For a permanent resolution, the development team might want to consider:

  1. Reviewing the text input handling library implementation
  2. Implementing proper Japanese IME event handling

Additional Technical Context

The fact that this issue:

  • Only occurs with Japanese input
  • Only affects single-line text fields
  • Appeared around the time of localization updates

Strongly suggests this is related to either:

  1. IME event handling in the input component library
  2. Recent changes in the input handling system related to localization

I hope this analysis helps in identifying and resolving the issue. Please let me know if you need any clarification or have additional observations to share.

Thanks for these details!

Thanks for reporting this - I'll be ramping up a fix for this after the holidays so keep an eye out in the release notes.

Hi @takuya_miyai @AleksiAlkio @amyplin 

I've noticed that the issue seems to be resolving in some of my free accounts. While we'll need more time to confirm if this represents a complete fix, it's an encouraging sign. We'll continue to monitor the situation.

The bug fix is out to 100% Free users but we are in a code freeze during the holidays so the rest of the ramp up will happen in January! 

Hi @amyplin 

Thank you very much for looking into this issue and planning to implement a fix. We look forward to seeing the update in the release notes.

@amyplin 

I have conducted verification tests on my free AppSheet accounts as of December 21, 2024, 10:00 AM JST. Here are the detailed results:

Test Case 1: App Editor - Action Configuration

Tested: Japanese text input when adding a new Action via the Actions menu

Result: Not Fixed

movie-01.gif

Additional findings:

  • The same issue persists in Data, View, Format rules, and Automation menus
  • Note: Expression Assistant has never exhibited this issue, so it remains functional as expected

Test Case 2: App Editor - Preview Mode

Tested: Japanese text input in Text fields within the Preview screen

Result: Fixed

movie-02.gif

Test Case 3: Desktop Mode

Tested: Japanese text input in Text fields

Result: Fixed

movie-03.gif

Summary of Current Status

For App Creators:

  • The issue still persists in the App Editor during app configuration
  • This means app development work is still affected by the bug

For App Users:

  • The fix has been successfully implemented in Desktop mode
  • This represents a significant improvement for all end users

This partial fix represents progress, particularly for end users, though App Creators are still experiencing issues during development work.

ah yes thanks for the clarification. The fix is only for the App, I'll create a new ticket for the issues in the Editor.

Top Labels in this Space