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 bbe62d88d2.
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
- 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.
This commit ensures that tracked properties added to the post model are correctly synced when using `post.updateFromPost`.
It also introduces a plugin API to allow plugins to register new tracked properties in the post model without needing to modify the class.
Animating the background-color property like this is not compositable for the browser, which means the animation is not smooth, and can contribute to the Cumulative Layout Shift web vital.
For now, we're removing this, and may consider re-introducing an alternative version in future based on user feedback.
Non-admin/moderator users can bulk select items in new/unread, but not in
latest/top/hot. This commit ensures that when the user can no longer
bulk select items in a list, the bulk select checkboxes in the topic list
rows are hidden.
A lot of the data of fields is decided at insertion time and is not dynamic afterwards, this commit attempts to solve this problem by making the fk-field-data a component with getters on the all the properties we need. It allows for example to implement a dynamic @disabled without having to pass @disabled everywhere. Generally speaking this solution limits props-drilling.
@format has received the same treatment than @disabled.
Followup ccc8e37dde
The fix above was good, but I would prefer to give
the option of untranslated vs translated label like
I have for other admin components for consistency.
The chart component was not rerendering if the chart
config passed to it was changed, this commit fixes the issue
by getting the config from `this.args` before trying to
access it inside an async call, so if the args change Ember
correctly rerenders. Also adds tests for this and general
chart rendering.
---------
Co-authored-by: Martin Brennan <martin@discourse.org>
Sometimes changes to "What's new?" feed items are made or the feed items are
removed altogether, and the polling interval to check for new features is 1 day.
This is quite long, so this commit introduces a "Check for updates"
button for admins to click on the "What's new?" page which will bust
the cache for the feed and check again at the new features endpoint.
This is limited to 5 times per minute to avoid rapid sending of
requests.
Using Ember's `<template>` dynamically is not supported. For every invocation, glimmer-vm has to run one-time setup, and will cache the result indefinitely. This leads to significant memory leaks, and eventual OOM errors.
This commit updates a handful of cases. We'll be following up with the more complex ones, and a linting rule to avoid re-introducing the problem in future.