Implement custom accessible dropdown toggle labels for forum components
Making the a11y label more specific to the specific action it performs is critical for good UX with assistive technologies.
When the composer is opened while scrolled to the absolute bottom of the page (via hitting the "reply" button, `window.scrollTop` has a value of ~600px greater than it should. This doesn't seem to be the composer element's height (which appears to be 0 at the time). This incorrect scrollTop positions the composer off screen, which causes Safari to freak out and shake the element violently as it tries to scroll to the cursor (which is now off screen).
We can get around this by calculating scrollTop ourselves.
Fixes https://github.com/flarum/core/issues/2683
- Split user edit permision into edit attributes, edit credentials, and edit groups
- Only Admins can edit Admin Credentials
- Only Admins can Promote/Demote to/from Admin
Followup to https://github.com/flarum/core/pull/2524.
In that PR, we fixed infinite scroll for the panel, but accidentially used document.body. Since scrollTop on body is (almost always) 0, this means that new pages of notifications were loaded on every scroll, which quickly becomes overwhelming. Instead, we can use `document.documentElement` for getting scrollTop, which results in the expected behavior.
* Don't update scrubber while post pages loading
This alleviates the scrubber bouncing around when scrolling up on iOS
* Throttle loadMore loadPrevious
Throttle loadMore and loadPrevious functions to alleviate skipping over pages and pages of posts during one scroll. This sometimes happens on iOS
Improves calculations for determining whether we are at the bottom of the notifications panel (which would trigger infinite scroll). This should be particularly effective in fixing issues on smaller screens.
- Anchor scroll when inserting post placeholders
- Indicate that pages are loading at start of `loadPage`, which allows `onscroll` to not request that multiple pages be loaded at the same time
These changes are particularly applicable to firefox, where previously, dozens of posts could be skipped at a time if scroll up was held while at the top of the viewport.
- Support slug drivers for core's sluggable models, easily extends to other models
- Add automated testing for affected single-model API routes
- Fix nickname selection UI
- Serialize slugs as `slug` attribute
- Make min search length a constant
Although native browser scroll restorations have become quite powerful, it interferes with Flarum's PostStream, so if we're on a DiscussionPage, we use manual scroll restoration.
In the PostStream, `this.visibleEnd` represents the index of the last post + 1, but `loadNearIndex` treated it as if it was the index of the last post. This means that executing `goToIndex` on the post stream's current `this.visiblePost` didn't load new posts, and as a result, the requested scrolling did not occur.
This prevents an edge case where `app.discussions` is considered empty while the new page is loading, and as a result, the side pane isn't set as "enabled". Then, if the pane has previously been pinned, when the page loads and the side pane appears, it covers up part of the discussion page.
Fixes https://github.com/flarum/core/issues/2471
- Reintroduce cancellable scroll top on page change
- IndexPage: rely on browser to retain scroll position on page reload
- Remove obsolete browser hack
- Fix broken selector
- When on mobile, only retain scroll for IndexPage if we're coming from a discussion
- Move app.cache.scrollTop save into `onbeforeremove` so we make sure to do it before DOM is detached
The default first post number is '1', so we scroll to that if we're calling `m.route.set` without a `near` parameter, as that means we're scrolling to the top.
This was present in beta 13's implementation, but accidentially omitted in 988b6c9.
We also remove unnecessary typecasting for simpler logic and increased consistency with beta 13.
The current implementation for checking whether we are on a discussion page, and going to a discussion page, checks the route we are going to. This is problematic, because the route resolver represents the route being considered, not the route we are currently on. So, if we are currently using a DiscussionPageResolver, we must be going to a route handled by DiscussionPage. Instead, we need to check the route that we are currently on, which is done via `app.current.matches(DiscussionPage)`.
- mapRoutes: don't wrap components in resolvers if they are already resolvers
- Extract defaultResolver into its own class
- Allow either route resolver instances, or components with an optional resolverClass which should accept the component and route name in its constructor.
- Introduce a resolver for DiscussionPage, so that routing from one post to another on the same discussion triggers a scroll instead of rerendering
- Add an index to reply placeholder so we can scroll to it directly when replying.
- Stop pretending that the currently broken `bottom` scroll functionality works, and explicitly call it `reply` scrolling to be clearer
- Directly get target from state
- Explicitly scroll to placeholder on reply
- Clean up scrollToItem code a bit
- Account for edge case where index is undefined when scrolling to post
Co-authored-by: Wadim Kalmykov <36057469+w-4@users.noreply.github.com>
Essentially, whenever a route is loaded, we add a key to that component. If the key changes, the page completely rerenders. Switching between different routes handled by the same key triggers those rerenders.
