This commit includes various accessibility improvements for the new user menu:
* Add `title` attributes to the user menu tabs
* Properly label lists (by adding `aria-labelledby` to `<ul>` elements) for screen readers
* Change the user menu structure so that the tabs come before the content panel in the DOM, but use CSS to reverse them visually.
Normally, changing the order of elements via CSS is bad for accessibility, but I believe this is one of the rare scenarios where it [makes sense](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible_Box_Layout/Ordering_Flex_Items#use_cases_for_order). Prior to this change, if you want to reach the first notification item after you select a tab using the keyboard, you have to hit <kbd>ctrl</kbd>+<kbd>tab</kbd> because the notifications list is before the tabs list. However, with this change, <kbd>tab</kbd> will move you to the first item in the list after you select a tab using your keyboard.
* Aria-hide the unread notifications badge/count on the tabs because the `title` attribute on the tab indicates the unread count.
* Add some tests.
The key fix in this commit is that it removes `this.replaceState(path)` for anchor-only URLs. We still intercept those routing changes to properly calculate the scroll position of the anchor via `jumpToElement`, but we no longer use the Ember router to override the browser's history. This fixes the subfolder issue and also lets the browser maintain its history correctly.
The commit also includes a small refactor to the `jumpToElement` helper to facilitate stubbing in tests.
This PR restores a small feature which was present in the old menu and allowed users to click on the active tab in the menu to navigate to some page that showed the same items in the menu but with more details.
For example, if you switch to the PMs tab and then click on it again, currently nothing happens. However, with this change, clicking on the tab again will take you to your messages page at `/my/messages`.
Note: plugins that register custom tabs in the menu can provide a `linkWhenActive` property for their tab if they wish to mimic core's tabs, but it's optional; if they don't provide one, the tab will do nothing if the user clicks on it again.
Internal topic: t/73349.
Because Discourse is a single-page application, clicks on the majority of `<a>` elements in the app need to be intercepted by JavaScript to prevent browsers' default action (full page reload). Links in the user menu - which include notifications, reviewables, bookmarks etc. - are no exception to this rule and currently clicks on these items are handled by the global [click-interceptor](1fa21ed415/app/assets/javascripts/discourse/app/lib/intercept-click.js (L20)) which calls the `preventDefault` function on the click event object and uses the `DiscourseURL.routeTo` function to route the user to the page they request.
However, for links in the user menu, there's an extra step which is to let the header know that it should close the user menu after clicking an item in the menu, but the global interceptor doesn't know that because the step is specific to links in the user menu. This can cause a bug on mobile devices where the menu remains open after clicking on a notification which results in the user having to close the menu to see the page that the notification takes them to.
This commit adds a click handler to user menu items that ensures the menu is closed when an item is clicked and navigates the user to wherever the item links to. There's a small downside to this change which is that user menu items now have their own click interceptor instead of relying on the global interceptor, i.e. duplicated logic, but since it's only a couple of lines, I think we can live with it for a while.
I did try to make the click handler of the user menu items only close the menu (call the `closeUserMenu` function), but for some reasons it caused a full page reload to happen when clicking a notification item due to some weird interactions between the header widget and the user menu. I didn't debug this thoroughly because we have plans to change the header implementation from widgets/virtual-dom to Glimmer component, which will likely resolve that weird full page reload issue and we'll be able to make the click handler just close the menu and let the global interceptor prevents the default action and do the routing.
Internal topic: t/71911/118.
This commit adds to the experimental user menu a new "other notifications" tab that's very similar to the "all notifications" tab, but with the main difference being that it doesn't show notification types that do have dedicated tabs in the menu (e.g. mentions, likes, replies etc.).
The rationale behind this is that the notification types that do have dedicated tabs tend to dominate the "all notifications" tab, leaving very small chances for the user to notice rarer or infrequent notification types. Adding a tab for all the other types gives the user a way to review those infrequent notification types.
Internal ticket: t72978.
Co-authored-by: OsamaSayegh <asooomaasoooma90@gmail.com>
If the server is configured to use a view like `categories_and_latest_topics`, it will preload data for the topic list. If the client doesn't actually use it (e.g. on mobile), then that preloaded data would remain cached and be used for the next loaded topic list. This commit ensures it's always removed, and adds a test for the behaviour.
https://meta.discourse.org/t/237126/35
Each new user menu notifications should have their own count. Therefore, we need to include all types to serializer and not only `grouped_unread_high_priority_notifications`
Additional PR will be created for chat and assign plugin, as they will have to switch to `grouped_unread_notifications` as well.
When installing private themes and theme components, the public key does
not show until the administrator types a valid Git repo URL. The regular
expression that checked the URL was too strict and it required the URL
to end with ".git".
When you receive a new notification, Discourse prepends a small count `(n)` to the tab title (i.e. `document.title`) if the tab is in the background to alert the user that they have a new notification. The count that's shown in the tab title should reflect the numbers shown on the notification bubbles above the user's avatar. Prior to the experimental user menu, there were 2 bubbles: a blue one which was removed once the user opened the menu and a green one that indicated high priority notifications and it was only removed when the user read all of their high priority notifications.
In the new experimental user menu, we no longer have the green bubble; everything is now combined (including flags/reviewables) into the blue one with no change to its behavior (i.e. it's removed once the user opens the menu). However, the logic that is responsible for updating the tab title hasn't been updated and still updates the tab title to include the count of the old green bubble. This commit updates the logic for the tab title count so that it only reflects the number on the blue bubble when the experimental user menu is enabled.
We were already compiling the markdown bundle via ember-cli, but that version was only being used in the test environment. This commit improves the implementation, and updates the filename so it's also used in production.
This commit also
- Removes the vendored copy of `markdown-it.js` and fetches from node_modules instead
- Updates `pretty_text.rb` to remove the custom sprockets-manifest-parsing
- Removes `pretty-text-bundle.js`, which was only being used by `pretty_text.rb`
This adds a new framework for accessible dialogs that will eventually replace bootbox. Under the hood, it uses the a11y-dialog package and an in-repo Ember addon. See PR for usage details.
The old logic did not make sense and hid the selector from regular users
even if they could tag PMs or showed selector for admins even if they
could not tag PMs.
This commit extends the plugin API introduced in 40fd82e2d1 to the `Bookmark` and `Notification` models. It also refactors the code that's responsible for loading items in the experimental menu to use `async`...`await` instead of `Promise`s.
This API allows plugins to transform a list of model objects before they're rendered in the UI. At the moment, this API is limited to items/lists of the experimental user menu, but it may be extended in the future to other parts of the app.
Additional context can be found in https://github.com/discourse/discourse/pull/18046.
Plugins often change core behavior, and thereby cause core's tests to fail. In CI, we work around this problem by running core CI without any plugins loaded.
In development, the only option to safely run the core tests is to uninstall all plugins, which is clearly a bad developer experience. This commit aims to improve that experience.
The `qunit_skip_plugins=1` flag would previously prevent the plugin **tests** from running. This commit extends that flag to also affect the plugin's application JS.
Default sidebar tags for not authenticated users can be defined in admin panel. Otherwise, top 5 categories and tags are taken.
Optionally, if categories are set up in permanent order, then the first 5 categories are taken.
