fix(chat-flow): repair the option-row layout, dark theme, and the newline hint (1.0.7)#43
Merged
Merged
Conversation
…line hint (1.0.7) Three defects in the visual flow editor, all reproduced in a running dashboard before and after the change. The option rows were unusable. `input[type="text"]` sets width:100% and, as an element+attribute selector, has specificity (0,1,1) — which beats the bare `.node-key` class at (0,1,0). The key field therefore stretched across the whole flex row and pushed the reply textarea and the row's buttons outside the panel, clipped and unreachable, so a menu could not be edited at all. The rule is now `input.node-key` and carries its width through flex-basis, so it holds even if the stylesheet is later reordered. The greeting placeholder read "Hi! Please choose:\n1. Hosting" with a literal backslash-n, because \n in an HTML attribute is two characters, not a line break. It modelled input that the plugin sends to WhatsApp verbatim. It now uses and shows the example across real lines. The editor was light-only, so on a dark dashboard it rendered as a bright panel inside a dark dialog. Colours now come from custom properties with a dark override, driven by the theme the host reports in the config handshake (OpenWA 0.10.5+). The sandboxed iframe has an opaque origin and cannot read the parent's theme itself, so without that field it can only guess; `prefers-color-scheme` remains the fallback for an older host, which keeps this working either way.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the editor defects behind OpenWA#853.
1. The menu-option rows were unusable
Each option row rendered with its key field stretched across the full width, pushing the reply textarea and the row's Remove / Sub-option buttons outside the panel where they were clipped and unreachable. A menu could not be edited at all — which matches the report.
The cause is a specificity collision.
input[type="text"]setswidth: 100%and, as an element plus attribute selector, scores (0,1,1) — which outranks the bare.node-keyclass at (0,1,0), so the 72px width never applied. The rule is nowinput.node-keyand carries its width throughflex-basisas well, so it survives a future reordering of the stylesheet.2. The greeting placeholder taught the wrong format
It read
Hi! Please choose:\n1. Hosting\n2. Supportwith a literal backslash-n, because\ninside an HTML attribute is two characters rather than a line break. That is worse than cosmetic: a\ntyped into the greeting is delivered to WhatsApp exactly as written. The placeholder now uses and shows the example across real lines.3. The editor ignored the dashboard's dark theme
It was light-only, so on a dark dashboard it appeared as a bright panel in the middle of the dialog.
Colours now come from custom properties with a dark override, applied from the theme the host reports in the settings handshake (OpenWA#860, OpenWA 0.10.5+). The sandboxed iframe has an opaque origin and cannot read the parent's theme itself, so it can only be told.
prefers-color-schemestays as the fallback, which keeps the editor readable on an older host that sends nothing — so this is safe to release ahead of the host change.Verification
Reproduced in a running dashboard before the change and re-checked after, in both themes: the option row lays out correctly (narrow key, reply text filling the space, both buttons visible), and the editor matches the dashboard in light and dark.
Suite 405/405,
tsc --noEmitclean, catalog regenerated.