I'm not sure if this is a real-world consideration... but our `test/smoke-test.mjs` script runs chrome with `--disable-local-storage`, so it needs to work.
This commit introduces a new 'dev tools' feature for core, theme and plugin developers. This is enabled by default in development environments, and can be enabled in production by running `enableDevTools()` in the browser console.
When enabled, it will load a separate dev-tools JS/CSS bundle, and show a new toolbar on the left of the page. Dev Tools will remain enabled until the 'x' button is clicked, or `disableDevTools()` is run in the console.
The toolbar currently has three buttons:
- "Toggle safe mode" provides an easy way to toggle all themes/plugins on/off
- "Toggle verbose localization" is a toggle for our existing locale debugging feature
- "Debug plugin outlets" is inspired by the popular 'plugin outlet locations' theme component. It hooks into core's plugin outlet system, and renders a button into every single outlet. Those buttons have a tooltip which shows more information about the outlet, including all of the outletArg values. To inspect the value further, buttons allow the values to be saved to globals and logged to the console.
All of this is implemented under `/static`, and is only async-import()-d when the dev tools are enabled. Therefore, we can continue to add more tools, with zero performance cost to ordinary users of Discourse.
This will cause the glimmer topic-list to be enabled for sites with compatible customizations. Incompatible customizations will print a deprecation message to the console, along with a link to more information.
Also cleans up a handful of specs/behaviour which were revealed by switching the default.
More details at https://meta.discourse.org/t/343404
Now that we correctly await for the modal to close, we dont need to special case and disable focusTrigger, the flow will now be:
- click an element of the menu
- wait for modal to close
- focus trigger
- trigger action, which will eventually open a modal and attempt to focus the first item
The chat emoji picker is renamed emoji-picker, and the old emoji-picker is removed.
This commit doesn't attempt to fully rework a new emoji-picker but instead tries to migrate everything to one picker (the chat one) and add small changes.
Other notable changes:
- all the favorite emojis code has been mixed into one service which is able to store one state per context, favorites emojis will be stored for all topics, and for each chat channel. Meaning that if you always use a specific emoji in a channel, it will only show as favorite emoji in this channel.
- a lot of static code has been removed which should improve initial load perf of discourse. Initially this code was around to improve the performance of the emoji picker rendering.
- the emojis are now stored, once the full list has been loaded, if you close and reopen the picker it won't have to load them again.
List of components:
- `<EmojiPicker />` will render a button which will open a dropdown
- `<EmojiPickerContent />` represents the content of the dropdown alone, it's useful when you want to render a picker from an action which is not the default picker button
- `<EmojiPickerDetached />` just a simple wrapper over `<EmojiPickerContent />` to make it easier to use it with `this.menu.show(...)`
---------
Co-authored-by: Renato Atilio <renatoat@gmail.com>
This adds the Silence Reason column to silenced user lists.
This feature helps combat large spam attacks cause you can quickly see
why a user was silenced and then bulk act on all the silenced users
Meta topic: https://meta.discourse.org/t/full-name-at-sign-up-went-missing/345662/17?u=osama
The preloaded `site` object for anons on login-required sites is a stripped down version of the full object with just a specific set of attributes and doesn't use the site serializer. This results in the `full_name_required_for_signup` and `full_name_visible_in_signup` attributes not making it to the client app when a login-required site is accessed by an anon, causing the name field in the signup form to not be rendered, even when it's required.
This commit includes those attributes in the stripped down version of the `site` object that's used for anons on login-required sites.
This commit introduces a workaround for a behavior observed in Safari for iOS / iPadOS where the feedback message wasn't being displayed after clicking on the copy button in the Glimmer post menu
This test is flaky, sometimes it fails with the hamburger menu blocking the click on the emoji, other times it just doesn't return the list of emojis when the search term is there.
Other similar emoji tests are skipped. Stopping the bleed, but we still need to figure out a more reliable testing strategy here.
Will revisit after #28277 is merged.
ref /t/-/145212
Nokogiri/libxml is now more strict in terms of params it receives.
It uses kwargs vs options object (I fixed an issue there in #30545) doesn't accept nil/blank html (fixed here) and most importantly handles encoding in a different way. It seems to require explicitly specifying UTF8.
* Build(deps): Bump nokogiri from 1.16.8 to 1.18.1
Bumps [nokogiri](https://github.com/sparklemotion/nokogiri) from 1.16.8 to 1.18.1.
- [Release notes](https://github.com/sparklemotion/nokogiri/releases)
- [Changelog](https://github.com/sparklemotion/nokogiri/blob/main/CHANGELOG.md)
- [Commits](https://github.com/sparklemotion/nokogiri/compare/v1.16.8...v1.18.1)
---
updated-dependencies:
- dependency-name: nokogiri
dependency-type: direct:production
update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* FIX: Wizard improvements post-merge part 1
Followup 3135f472e2
Fixes the following:
* On mobile, the Styling step was very narrow
* When clicking Next on the Styling step after previously
selecting Hot, we got an error
Also makes the following UX improvements for the preview:
* Use different topic titles for Latest and Hot
* Also make Hot view and reply numbers higher
This helps differentiate the two previews.
* DEV: Review fixes
Followup c2282439b3
Make the Files and Other config pages reached from the sidebar
use our consistent site setting page rules.
Also slightly improves AdminAreaSettings so we don't show
"Settings not found" when still loading settings.
When inserting anything from the chat composer dropdown, any popups opened weren't properly focussed.
This was due to the default behaviour of the dropdown menu closing, which tries to return the focus to the original triggering element. This would normally be the correct behaviour, but here we want the menu to close in the background, handing focus off to the popup, instead.
Create a basic config page that only contains Onebox-related settings, to replace the "onebox" category view linked to from "Onebox" in the admin sidebar.
Create a basic config page that only contains user API-related settings, to replace the "user_api" category view linked to from "User API" in the admin sidebar.
Create a basic config page that only contains rate limiting-related settings, to replace the "rate_limits" category view linked to from "Rate limits" in the admin sidebar.
Create a basic config page that only contains developer-related settings, to replace the "developer" category view linked to from "Developer" in the admin sidebar.
Create a basic config page that only contains security-related settings, to replace the "security" category view linked to from "Security settings" in the admin sidebar.
Followup 3187606d34
Fix full_name_requirement INSERT by adding ON CONFLICT DO NOTHING,
on sites that already have this setting this migration will fail.
Create a basic config page that only contains security-related settings, to replace the "security" category view linked to from "Security settings" in the admin sidebar.
Back then in 31e31ef, we added the Content-Disposition headers so that SVGs get downloaded instead of get run in the browser. Inadvertently, this also causes other attachments like pdfs and videos to be downloaded instead of heeding the "Open in new tab" option that users choose in the browser.
When the header is removed, the default value is "inline", this allows the browser to perform as requested. This also applies to other file types like pdfs, allowing users to "Open in new tab" and view them in the browser instead of always downloading them.
Existing tests (#10205) already do check that SVGs remain downloaded. Some existing tests written for PDFs have been modified to cater for SVGs instead, when there was a bug in defining the filenames per #10108