fix: enable scroll in text input when no text

[32teeth]

Problem

The text input field in the chat prompt component doesn't allow scrolling when no text is present, causing usability issues. The placeholder text width doesn't adjust dynamically, leading to improper alignment and a poor user experience.

Solution

• Enabled dynamic scrolling behavior in the text input field when no text is present by adding the overflow-x: scroll property and ensuring scrollbars are hidden when there's no content.
• Added a new function getPlaceholderWidth to dynamically calculate and set the placeholder width based on the text content.
• Updated styling in _chat-prompt-wrapper.scss to ensure proper handling of the placeholder text width and scrollbar behavior.
• New SCSS/CSS variable --mynah-placeholder-width
  • Default set to 100%
  • When getPlaceholderWidth as a subscriber is called, returns and sets value for --mynah-placeholder-width using style: this.getPlaceholderWidth()

Bonus

[!TIP] import open from'open'; spacing issue and module / mjs was complaining

• Updated dev.js to handle file opening errors using a dynamic import.

[!TIP] Although we have watchers, added serve:example for refreshing developer environment without refreshing browser (wasn't working previously as intended as CMD+F5 had to be invoked

• Added new scripts in package.json to improve development workflow, including watch:web and serve:example commands.

License

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[dogusata]

Another very important point for these kind of changes that they need UX team approval first before implementing these kind of changes. Previously these kind of changes were caused several unexpected UI behaviors and visual regressions. Unless they're precisely investigated and clearly requested from the UX team, we're not changing behavior or the style of the components. For example, they may prefer to have a tooltip or shorten the placeholder since it already has an ellipsis. Also, there is already an ongoing progress for the discoverability of the features through the welcome message instead of relying on the placeholder of the prompt text.

I would strongly suggest contact with the UX team first, and after that wait until the e2e integration test PR is merged. This change should also require a new/updated e2e tests with golden screenshot comparison. Only with that we can assure that we're not causing any visual regressions or unexpected behaviors.

[32teeth]

Another very important point for these kind of changes that they need UX team approval first before implementing these kind of changes.

Is there a best contact for the UX team?

[32teeth]

Thanks @dogusata for the intro to the UX/UI creative leads

This is the current behaviour of the GitHub Copilot experience (scrollable input box when empty, place holder only)

The implementation is pretty much a replication of those mechanics (super light weight)

I’d be okay to fast follow with a tooltip, before hand we’d need to assess all the use cases for the tool tip but that’s a tomorrow day kinda discussion

• does the tooltip only show when empty?
• Do we change the context of the tooltip based on the current tab type?
• Do we only show the tooltip if the panel is smaller than the text shown?
• …

Anyway, thanks for the reflection and remarks, I can do a follow up PR.

I’ll sign up for the Ui discussion next week to identify strategy and next steps

[32teeth]

CLosing to rebase and correct merge conflicts