Commit 68497bddf2 implemented a function
to format durations in a medium format, similar to how durationTiny did.
The existent translation strings do not cover all cases and this commit
adds the missing translation strings.
Firefox does not support window.ClipboardItem yet (it is behind
a flag (dom.events.asyncClipboard.clipboardItem) as at version 87.)
so we need to fall back to the normal non-async clipboard copy, that
works in every browser except Safari.
This commit also tests the clipboardCopyAsync function by stubbing out
the clipboard on the window.navigator.
This fixes an issue in the discourse-chat plugin, where the
"Quote in Topic" button errored in Firefox.
The links returned by post.url and topic.url are relative, but contain
the subdirectory. When getAbsoluteURL is called to construct the
complete share URL, it adds the host and the subdirectory again. As a
result the created URLs contained the subdirectory twice.
Meta topic: https://meta.discourse.org/t/rtl-direction-is-broken-in-quotes/217639?u=osama.
Posts in Discourse are by default always rendered in the same direction as the rest of site, for example if the site is RTL, a post in that site is always rendered RTL even if it's made of an LTR language entirely. However, this behavior can be changed by enabling the `support mixed text direction` site setting which makes our posts rendering engine consider each "paragraph" in the post and apply an appropriate direction (using the `dir` attribute) on it based on its content/language.
I put paragraph in quotes because technically we only loop through the immediate children of the HTML element that contains the post cooked HTML and do this direction check on them. Most of the time the immediate children are actually paragraphs, but not always. The direction of an element is determined by checking its `textContent` property against a regular expression that checks all characters are RTL characters and based on the regular expression result the `dir` attribute is set on the element.
This technique doesn't work so well on quotes because they may contain multiple paragraphs which may be in different languages/directions. For example: if a site's language is Arabic (RTL language) and the `support mixed text direction` setting is enabled, regular paragraphs outside quotes are rendered as expected with the right direction depending on the paragraph's language. However, paragraphs within a quote are all (incorrectly) rendered in a single direction, LTR or RTL, regardless of whether they're of different languages/directions or not.
The reason for this is that when we're determining the direction for the quote, it's considered as one element and the direction is set on the whole quote. But for complex quotes that contain mixed paragraphs, we need to be more surgical and apply direction on individual paragraphs/elements within the quote.
This commit adds special handling for quotes to ensure that:
* the quote top bar (the avatar plus the chevron and arrow) always match the site direction
* each immediate paragraph (`<p>` elements) under `<blockquote>` in the quote gets a direction based on its content.
For before/after screenshots, see PR #16004.
Allows to write custom code blocks:
```
```mermaid height=200,foo=bar
test
```
```
Which will then get converted to:
```
<pre data-code-wrap="mermaid" data-code-height="200" data-code-foo="bar">
<code class="lang-nohighlight">
test
</code>
</pre>
```
* Some are no longer flaky or easily fixed
* Some are out of date or test things we can't do accurately (scroll
position) and are removed.
* Unwinds some uppy tests and makes sure all promises and runloops are
resolved.
Everything has been run in legacy/ember cli multiple times to ensure no
obvious suite regressions.
* The current evaluation of uppy promises is causing the entire suite to fail
if there's an exception. Instead of using `done` we use the simpler
pattern of returning the promise from the test to force Qunit to wait
until it's completed.
* In some browser conditions `/last.json` will be requested depending on the
particular scroll / performance. This causes the tests not to fail if
that is the case.
* Keyboard shortcuts were not being fully cleared between runs,
resulting in tests failures.
This means that our DiscourseURL logic will work consistently in tests, where `window.location` doesn't get updated.
To make it work properly, our `replaceState` implementation needed to be updated so that it writes the new URL to Ember's router, rather than bypassing the router and going straight to the `location` API.
A couple of tests needed updating following this fix:
- the composer-test was asserting that the new reply should be missing from the DOM... when really it **should** be in the DOM, and this fix to the test environment makes it so
- the topic-test was making a fake topic fixture based on the data from a topic with a different id. This was causing the topic route to get confused, and 'fix' the currentURL. This commit updates it to use a fixture with consistent data.
This commit also removes the feature detection of `window.history`. It's feature-detected within `discourse-location`. Plus, we don't support any browsers without it.
Previously only `<div>one top element</div>` was allowed because we use `firstChild` instead of `children`.
We also want `<div>one</div><div>two</div>` to work with this method.
This commit extends the options which can be passed to
`PrettyText.markdown` so that which Markdown-it rules and Discourse
Markdown plugins to be used when rendering a text can be customizable.
Currently, this extension is mainly used by plugins.
It was impossible to select the 'all' filter for categories that have
the default list filter set to 'no subcategories'. This happens because
'/all' was not appended to the URL and in the absence of any list filter
('all' or 'none'), the default list filter ('none') was automatically
selected.
The commit 20b2a42f49 broke
upload handlers, because previously we passed through the
native File object to the handler, not the uppy-wrapped
File object.
Time spent in the 'find module with suffix' portion of our `customResolve` function were adding up to around 100ms-150ms when booting the app. This time is spread over 150+ calls, so it's not immediately obvious in flamegraphs.
This commit implements a (reversed) [Trie](https://en.wikipedia.org/wiki/Trie) which enables fast suffix-based lookups on a list of strings.
In my tests, this requires < 5ms to initialize, and brings the cumulative 'find module with suffix' time down to `< 5ms`. This corresponds to a ~100ms improvement in LCP metrics in my browser.
The only behavior change is to remove support for module filenames which are **not** dasherized. I haven't found any core/theme/plugin modules which are not dasherized in their filenames.
* FIX: do not display add to calendar for past dates
There is no value in saving past dates into calendar
* FIX: remove postId and move ICS to frontend
PostId is not necessary and will make the solution more generic for dates which doesn't belong to a specific post.
Also, ICS file can be generated in JavaScript to avoid calling backend.
It allows saving local date to calendar.
Modal is giving option to pick between ics and google. User choice can be remembered as a default for the next actions.
We want to be able to skip plugins from doing any work under
certain conditions, and to be able raise their own errors if
a file being uploaded is completely incompatible with the concept
of the plugin if it is enabled. For example, the UppyChecksum plugin
is happy to skip hashing large files, but the UppyUploadEncrypt
plugin from discourse-encrypt relies on the file being encrypted
to do anything with the upload, so it is considered a blocking
error if the user uploads a file that is too large.
This improves the base functions available in uppy-plugin-base and
extendable-uploader to handle this, as well as introducing a
HUGE_FILE_THRESHOLD_BYTES variable which represents 100MB in bytes,
matching the ExternalUploadManager::DOWNLOAD_LIMIT on the
server side.
discourse-encrypt to take advantage of this new functionality will
follow in discourse/discourse-encrypt#141
We want to be able to skip plugins from doing any work under
certain conditions, and to be able raise their own errors if
a file being uploaded is completely incompatible with the concept
of the plugin if it is enabled. For example, the UppyChecksum plugin
is happy to skip hashing large files, but the UppyUploadEncrypt
plugin from discourse-encrypt relies on the file being encrypted
to do anything with the upload, so it is considered a blocking
error if the user uploads a file that is too large.
This improves the base functions available in uppy-plugin-base and
extendable-uploader to handle this, as well as introducing a
HUGE_FILE_THRESHOLD_BYTES variable which represents 100MB in bytes,
matching the ExternalUploadManager::DOWNLOAD_LIMIT on the
server side.
discourse-encrypt to take advantage of this new functionality will
follow in https://github.com/discourse/discourse-encrypt/pull/141
There was a check for closed code blocks (which had both opening and
closing markups), but it did not work for the case when the text ends
in an open code block.
This abstracts interaction with uppy for uppy plugin classes
into base classes for Preprocessor plugins, so anyone
making these uppy plugins doesn't have to think as much about uppy
underneath the hood. This also makes the logging and validation
nicer, and provides a more consistent way to emit progress and
completion events.
In a future commit, we will introduce another base class for
`UploadUploaderPlugin` which will be used to be able to hijack
the upload process to go to a different provider (e.g. for discourse-video)
