Have one inbox row and focus on it. Mark the message as read in
another tab. Press `r` in the first tab will return an error as
the row_focus didn't change but there is no present. So, we
fix it by updating the row_focus if it can get out of bounds
when updating inbox view.
This commit refactors the common function used for test in
such a way that we can test more cases for a group setting
along with the ones tested by the common function.
This commit is part of a bigger project to remove custom logic in
the input_pill module. This commit move us away from a world where
we have a `display_value` that's used as identifying information
for a pill as well as for what we display to the user. Now individual
widgets can configure how they come up with a display value based
on the data of that type of pill.
Note: The change in the stream pill test for setting subscribers
for denmark is fixing an issue that wasn't discoverable before.
There always should have been three subscribers.
We no longer need to do `robust_url_decode` because we're
creating the display value ourselves, whereas previously
we were using `Filter.unparse` which does encoding.
By using a custom `generate_pill_html`, we can remove the
`has_stream` logic in `input_pill`, as part of a wider effort
to remove custom pill logic in `input_pill`.
This is part of a larger effort to refactor input_pill to
remove custom logic and move it into relevant modules.
This commit completely removes group_id from all modules, but
there's another module that uses stream that must be refactored
before that can be removed from input_pill.
This is part of a larger project to move custom
logic out of input_pill. The `generate_pill_html`
function will be used for other modules in upcoming
commits.
This keeps colors uniform between edit and preview modes, and also
ensures no bleedthrough of the editor when in preview mode.
ID selectors have been used for those colors to both keep the text
color declaration in the same place, and to avoid a dark-theme
specificity problem where the generic textarea took precedence over
the colors specified on the compose box's own textarea.
Function `message_helper.process_new_message` takes a
`RawMessage` and throws out `Message`. But here we are
passing it an already processed msg of type `Message`.
This is completely type unsafe. Since our purpose here is to
replace our old message object with a latest copy from
`message_store`.
We can do this directly without calling `process_new_message`.
With the refactoring of the rendered-Markdown area to use only
margin bottom, including in message-edit previewsk, these expensive,
general selectors are unnecessary.
Headings and horizontal rules, which do have margin-top, are zeroed
out elsewhere in the rendered-markdown file.
Because the compose-box resize logic is tied to the size of the
textarea, it's possible when resizing in preview mode that the
state of the compose box is not properly tracked. That's because
the height logic in `autosize_message_content` assumes a visible
textarea.
However, because both the textarea and the message preview area
occupy the same named grid area (`message-content`), and because
the preview area comes after the textarea in the DOM, when visible,
the preview area will automatically cover (and be sized to) the
textarea. And because the textarea remains observable in the DOM,
the compose box will obey the same expansion logic in preview mode
as it does in edit mode.
This check been present since
466beef6fe, but it seems unnecessary in
that the main logic handles there being 0 channels just fine, that's a
rare case (so not a useful optimization), and importantly, not calling
stream_list_sort.sort_groups for that transition resulted in
`stream_list_sort` having stale data structures, resulting in
exceptions if one tried to open the CHANNELS filter widget in the
newly-no-channels state.
When the caret in textarea is around the right end of the screen,
typeahead can overflow the window. To fix it, we use tippy's
mechanism to keep the tooltip inside the visible boundary.
Scroll to bottom button is visible for a few ms when switching
narrow to Inbox / Recent view while scrolling in message feed.
While we can end the transition faster to completely avoid the issue
for now but this seems like a more permanent and simpler fix
than to fiddle with CSS.
Using the existing tooltip template for the other "add emoji reaction"
element in message_controls results in the keyboard shortcut being
shown and avoids doing work to translate the string for every single
message containing emoji reactions.
Aman Agrawal
Sahil Batra
evykassirer
Karl Stolley
Alex Vandiver
Kenneth Rodrigues
afeefuddin
Varun Singh
Anders Kaseorg
Tim Abbott
Sayam Samal