- Inline mentions on posts
- Inline mentions on chat messages
- The user autocomplete for the composer
- The user autocomplete for chat
- The chat section of the sidebar
What is the problem?
There are two problems being fixed here:
1. When opening the composer, we are seeing multiple requests made to
the `/composer_messages` endpoint. This is due to our use of the
`transitionend` event on the `#reply-control` element. The event is
fired once for each transition event and the `#reply-control` element
has multiple transition events.
2. System tests have animations disabled so the `transitionend` event
does not fire at all.
What is the solution?
Instead of relying on the `transitionend` event, we can instead just
observer the `composerState` property of the `ComposerBody` component
and trigger the `composer:opened` appEvent with a delay that is similar
to the transition duration used for the `ComposerBody` component.
* UX: replace highlight vars in popup menu
* UX: replace highlight vars in autcomplete
* UX: replace highlight vars in menu-panel
* UX: update style guide
* UX: bulk replace highlight vars in various small appearances
* UX: added fadeout + hashtag styling
UX: add full name to autocomplete
UX: autocomplete mentions styling
UX: emoji styling user status
UX: autocomplete emoji
* DEV: Move hashtag tag counts into new secondary_text prop
* FIX: Add is-online style to mention users via chat
UX: make is-online avatar styling globally available
* DEV: Fix specs
* DEV: Test fix
Co-authored-by: Martin Brennan <martin@discourse.org>
* FIX: Better virtual keyboard detect on Android
Firefox has a bug where *sometimes* the visualViewport.height won't be
updated when the keyboard pops up until you scroll, making our composer
stay hidden behind the keyboard. This commit uses both window.innerHeight
and window.visualViewport.height using the minimum of both to check for
height changes.
For Chrome/Edge we feature detect the new VirtualKeyboard API and
opt-into it when the composer opens and use it to detect if a keyboard
is being draw. Opting into the API changes how the viewport is
calculated so we have to also change how the full height composer is
calculated. To minimize breakage we opt-out when the composer component
is destroyed.
This commit also moves the `--composer-ipad-padding` to only happen on
iPads.
Bug report at https://meta.discourse.org/t/-/228382
Previously we were calculating both the minimum and maximum widths for
SK dropdowns using this Popper modifier. The max. width calculation was
causing issues with dropdowns in Firefox and was also sluggish when
rendering.
This switches to using CSS calculations for max. widths. It adds a 600px
global maximum and targeted maximums for the category composer dropdown
and the bookmark list dropdowns.
The composer is displayed over the bottom part of the page. To make sure
that no content is covered by the composer, a bottom padding is added
equal to the height of the composer. When the composer is opened or
closed that padding is added after around 300ms because of a debounce.
This commit makes sure that the padding is added as soon as the composer
state changes by using a CSS custom property (variable) and transition
property for a smooth user interface.
A follow-up to #15117 and #15141. Applies the previous changes to PM-specific fields, makes the preview area take the all the available height of the composer, and unifies more spacing between composer elements.
Major changes included:
- better support for screen readers
- trapping focus in modals
- better tabbing order in composer
- alerts on no content found/number of items found
- better autofocus in modals
- mini-tag-chooser is now a multi-select component
- each multi-select-component will now display selection on one row
We want to remove completely our custom modal for uploading files in composer and directly trigger the system file picker.
This PR makes it happen. The fix is pretty simple since we already weren't using our custom modal on mobile. We just need to start using the same hidden <input type="file"> that we already use on mobile.
It seems to be pretty tricky to test opening a system modal so I haven't added new tests. We already have other tests for file uploading though. We directly trigger jquery-File-Upload plugin hooks in those tests - 3dda926cb2/app/assets/javascripts/discourse/tests/acceptance/composer-attachment-test.js (L89).
We don't want to show the draft checkmark in the composer when drafts are saved, as it’s a little bit distracting to see it keeps appearing and disappearing. Only in the case of error does it need to show anything, we will be showing a "drafts offline" warning as we did it before.
An important detail is that the warning was appearing and disappearing all the time too. Now, the warning won’t be flashing while a user is typing, it’ll be disappearing only when the draft was eventually saved.
