Adds setupEditor to ComposerEditor so it can setup/destroy events when the underlying editorComponent is switched.
Moves putCursorAtEnd uses (which implementation is textarea-specific) to TextareaTextManipulation.
Moves insertCurrentTime and a corresponding test, which is discourse-local-dates specific, to the plugin.
Moves applyList and formatCode from DEditor to the TextareaTextManipulation.
Moves DEditor._applySurround to TextareaTextManipulation.applySurroundSelection
Avoids resetting the textarea value on applyList and formatCode, keeping the undo history.
before this commit, when moving posts with freeze option, the rate limit was being applied leading to errors. This commit fixes that.
and also adds tests for the scenarios of moving posts with freeze option.
This was fixed in 5563e9dc03bc465ee484dcf2c07b1a1bf989ef79, but then regressed again by an unintentional change in 6f7c581a8066f19956ad43431333292243b2c72b
BEFORE: if you click the "reply" button on a post and then decided that you want to "edit" the same post, clicking the "edit" button would do nothing. Clicking "edit" on another post works, but editing the same post would appear broken.
AFTER: if you click the "edit" button, it will properly load the content of the post you're trying to edit. No matter which one it is.
This was somewhat tricky to track down as the system specs seemed to contradict the qunit tests until I realized that the qunit tests were only testing the edit on the 1st post and the system specs were testing on replies.
I improved the qunit tests to test both editing OP and a reply and (hopefully) made the system specs a little bit clearer.
This is a follow up to bbe62d88d2554189e15f407736b1f7a01968c631.
Uses the `htmlClass` to automagically set the `modal-open` class to
`<html>` so that we can do `overflow: hidden` and prevent the
"background" behind the modal from scrolling while the modal is open.
Internal ref - t/142760
When serializing the `body_changes` in the `PostRevisionSerializer`, we create two diffs: one for the `cooked` and another one for the `raw` version of the post.
Inside `DiscourseDiff`, we generate both `html` and `markdown` diffs when we only need the `html` diffs for the `cooked` version of the post and the `markdown` diff for the `raw` version of the post.
This solves the issue repored in https://meta.discourse.org/t/server-error-accessing-topic-revisions-on-a-specific-topic/339185 where some revisions would return 500 because of a `ArgumentError : Attributes per element limit exceeded` exception when trying to generate the `html` diff on a very large `raw`.
This will ensure AI generated titles don't appear as out of range in the UI and also allow users to set longer titles. The limit in DB was already 100 so it's just a simple frontend change.
We were using a complex logic to make it change size based on scroll position but this was imperfect and not visually pleasing. Also the title had been made a button which was causing the ellipsis to not work correctly, and I would prefer to not mix page knowledge (thread) with title component so I made this click logic directly in the chat-thread component.
---------
Co-authored-by: Jordan Vidrine <jordan@jordanvidrine.com>
- Use `requestAnimationFrame` when transitioning from `ready` -> `loading`. The previous `next()` implementation was unreliable, particularly in Safari, and would cause the loading slider to jump backwards instead of forwards
- Double the minimum transition time to 200ms. This avoids the rolling average being skewed too much by routes which load quickly without network access.
