This reverts commit 2c7906999a.
The changes break some things in local development (putting JS files
into minified files, not allowing debugger, and others)
Currently when pressing Shift key and hitting Reply button the user
stays on the post they are on and does not get navigated to newly
created topic/PM/reply. This is fine for replies but creates confusion
when composing a new topic/PM.
This commits makes it such that pressing Shift key and Reply button
(or ctrl-shift-enter / cmd-shift-enter) works only for replies and not
for new topic/PM. The user will always be navigated to new topic/PM.
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 reverts commit ea84a82f77.
This is causing problems with `/theme-qunit` on legacy, non-ember-cli production sites. Reverting while we work on a fix
This is quite complex as it means that in production we have to build
Ember CLI test files and allow them to be used by our Rails application.
There is a fair bit of glue we can remove in the future once we move to
Ember CLI completely.
- Update the TOPIC_URL_REGEXP in `lib/url` so that `navigatedToPost` doesn't attempt to handle slug-less URLs. Slugs must contain at least one non-numeric character, so we can use that fact to make the regex more specific. We want slug-less URLs to be routed as a normal Ember transition, so that `topic-by-slug-or-id` can catch them and re-write the URL to include the slug.
- Update the `topic-by-slug-or-id` afterModel to ensure that the Ember router is used to handle the redirect, rather than DiscourseURL. This guarantees that it will function as a redirect (DiscourseURL.routeTo sometimes bypasses the router). This solves the history problem which was worked-around in 27211ee7bb.
- Update routes/topic to recover from aborted transitions gracefully. This means that following an aborted transition, the browser URL continues to be updated with post numbers as the user scrolls down the page.
The new warnings cover more cases and more accurate. Most of the
warnings will be visible only to staff members because otherwise they
would leak information about user's preferences.
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.
…after you re-open the modal or select another emoji.
Reason:
Even the most used emoji would be knocked off the list after a while, if you use any emoji outside the recent. Consider the sequence:
✅, 😃, ✅ (from recent), 😀, ✅ (from recent), 😛, ✅ (from recent), 😎, ✅ (from recent), and so on
With the previous logic, the check mark emoji would leave the list, even though it used constantly and (and the time of removal) would the the second most recent used emoji.
---
It doesn't update the list when you use the recent list so that you can click an emoji repeatedly and it doesn't shift from under your mouse cursor.
The app's wrapper element ID is different in tests. `app.rootElement` allows us to consistently obtain the selector in the initializer, so it works correctly regardless of the app's configuration.
The test environment will wait for all timers to settle before continuing. These timers were causing all tests involving `/t/*` routes to spend 500ms doing nothing.
Fun fact: we load the topic route 214 times during the core test suite. That means that this commit saves a total of around 107s across the whole suite. On my machine, that's a 30% improvement in runtime.
Modern Ember only sets up a container when the ApplicationInstance is booted. We have legacy code which relies on having access to a container before boot (e.g. during pre-initializers).
In production we run with the default `autoboot` flag, which triggers Ember's internal `_globalsMode` flag, which sets up an ApplicationInstance immediately when an Application is initialized (via the `_buildDeprecatedInstance` method).
In tests, we worked around the problem by creating a fresh container, and placing a reference to it under `Discourse.__container__`.
HOWEVER, Ember was still creating a Container instance for each ApplicationInstance to use internally, and make available to EmberObjects via injection. The `Discourse.__container__` instance we created was barely used at all.
Having two different Container instances in play could cause some weird issues. For example, I noticed the problem because the `appEvents` instance held by DiscourseURL was different to the `appEvents` instance held by all the Ember components in our app. This meant that events triggered by DiscourseURL were not picked up by components in test mode.
This commit makes the hack more robust by ensuring that Ember re-uses the Container instance which we created pre-boot. This means we only have one Container instance in play, and makes `appEvents` work reliably across all parts of the app. It also adds detailed comments describing the hack, to help future travelers.
Hopefully in future we can remove this hack entirely, but it will require significant refactoring to our initialization process in Core and Plugins.
The mapping-router and map-routes initializer are updated to avoid the need for `container.lookup` during teardown. This isn't allowed under modern Ember, but was previously working for us because the pre-initializer was using the 'fake' container which was not ember-managed.
Migrate deprecated decorateCooked to decorateCookedElement for audio cloak-prevention.
This might give a minimal performance boost: running audio cloak-prevention for 20 (non-audio) posts takes 1 ms and not 15 ms.
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
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.
Before 6e0e6014, the flow looked something like:
1. `discovery/topics` controller (which extends `discovery` controller) `afterRefresh()` calls `.send("loadingComplete")`
2. Bubbles to [`discovery` route](https://github.com/discourse/discourse/blob/554ff07786a81ed55c902c074d5ba787cfda0a3b/app/assets/javascripts/discourse/app/routes/discovery.js#L58)
3. Discovery route calls `controllerFor('discovery').loadingComplete()`. `loading` is set false, and the spinner disappears
Now that `discovery/topics` defines `loadingComplete` as an action, the `discovery/topics` controller runs its own `loadingComplete` handler logic in step 1, and the action does not bubble any further.
This commit adds action overrides in `discovery/topics`, so that the new actions only apply to the main `discovery` controller. The need for this does suggest some more radical refactoring is required, but these are very critical routes, and we are very close to a major release.
This commit should be a no-op for all existing core outlets. Outlets which are introduced by themes/plugins may see a change in behavior, and should follow the steps below if they want to maintain their previous behavior.
`tagName="" connectorTagName=""` is almost always the correct choice for plugin outlets. 40eba8cd introduced a `noTags=true` shortcut which achieved this, and left a comment saying it should be the future default. This commit does exactly that. To avoid any breaking changes for plugins, all existing plugin outlets have been reviewed and adjusted by following this logic:
1) If `noTags=true`, remove the `noTags` parameter, and do not complete any further steps
2) If `tagName` is not specified, set `tagName="span"` (the previous default)
3) If `connectorTagName` is not specified, set `selectorTagName="div"` (the previous default)
4) If `tagName=""`, remove it
5) If `connectorTagName=""`, remove it
The updates were accomplished with the help of a ruby script:
```ruby
def removeAttr(tag, attribute)
tag = tag.sub /\s#{attribute}="?\w*"? /, " "
tag = tag.sub /\s#{attribute}="?\w*"?}}/, "}}"
tag = tag.sub /^\s*#{attribute}="?\w*"?\n/, ""
tag
end
files = Dir.glob("app/assets/javascripts/**/*.hbs")
puts "Checking #{files.count} files..."
files.each do |f|
content = File.read(f)
count = 0
edits = 0
content.gsub!(/{{\s*plugin-outlet.*?}}/m) do |match|
count += 1
result = match
noTags = result.include?("noTags=true")
tagName = result[/tagName="(\w*)"/, 1]
connectorTagName = result[/connectorTagName="(\w*)"/, 1]
if noTags
result = removeAttr(result, "noTags")
else
if connectorTagName == ""
result = removeAttr(result, "connectorTagName")
elsif connectorTagName.nil?
result = result.sub(/name="[\w-]+"/) { |m| "#{m} connectorTagName=\"div\"" }
end
if tagName == ""
result = removeAttr(result, "tagName")
elsif tagName.nil?
result = result.sub(/name="[\w-]+"/) { |m| "#{m} tagName=\"span\"" }
end
end
edits += 1 if match != result
result
end
puts "#{count} outlets, #{edits} edited -> #{f}"
File.write(f, content)
end
```
This workaround was introduced before we had the ability to render components with no wrapper element. Now we can pass `tagName=""` to `plugin-outlet`.
da6edc1 introduced the `lookupView` method, which initialized a fresh resolver, and used it to directly look up raw-views (with no caching). This worked well, but was not a clean solution. It required initializing an entirely new resolver, and did not have any caching.
This commit updates the `helperContext` to include access to the registry, and uses it to perform raw-view lookups. As well as re-using the registry, this also means we're making use of the resolver's built-in cache.
I haven't been able to measure any noticeable performance impact from this change, but there is certainly less work being done, so it may be beneficial on older devices.
Co-authored-by: Ayke Halder <rr-it@users.noreply.github.com>
If a theme/plugin raises an error while decorating post content, the decorator will be skipped, and the error reported on the console. Additionally, administrators will be shown a red warning at the top of the screen.
This commit refactors and re-uses some of the logic from the theme-initializer-error-reporting logic. In future, new error reports can be added by doing something like:
```
document.dispatchEvent(
new CustomEvent("discourse-error", {
detail: { messageKey: "some.translation.key", error },
})
);
```
- switches to a raster image QR code so it can be long-pressed (or right
clicked) and added to iCloud keychain
- adds `autocomplete="one-time-code"` to the 2FA input for better
discoverability
Meta topic: https://meta.discourse.org/t/cant-pin-unpin-topic-from-the-title/213444?u=osama.
I know there is an inconsistency between the category of the linked topic (#bug) and the title prefix of this PR, but I really couldn't find anything in the code base that suggested this ever worked before, so I'm categorizing this PR as a feature.
Running in production mode is useful when doing performance-sensitive work.
- Set the `exportApplicationGlobal` flag, so we get the `Discourse` global in production mode. It defaults to only adding the global in development mode. Note that, when generating ember-cli assets via rails, we set this in `ApplicationHelper#discourse_config_environment`.
- Disable SRI - Ember CLI adds this to index.html when in production mode. We don't use SRI in production, so disable here to match.
- Refactor the `AssetRev` logic in `ember-cli-build.js`, so that our custom bundle hashes are find/replaced into index.html. Without this change, our custom bundles (e.g. `start-discourse.js`) remain without their hash in `index.html`, and do not function.
I have confirmed that the only diff in the `/dist` out following this change is to the `index.html` file. All other filenames and contents remain identical.
Centralizes calculations in a helper under the site header component.
This also reverts a small CSS change to the composer: since ac79c5ef,
the composer height was not including the grippie, which means that the
composer height was off by 11 pixels, and the topic progress widget was
sometimes being displayed cut off by 11 pixels.
Joffrey JAFFEUX
Martin Brennan
Arpit Jalan
Robin Ward
David Taylor
Natalie Tay
Kris
Bianca Nenciu
Alan Guo Xiang Tan
Jarek Radosz
Rafael dos Santos Silva
Andrei Prigorshnev
Penar Musaraj
Ayke Halder
Dan Ungureanu
Meghna
Krzysztof Kotlarek
Osama Sayegh
Joe