This will properly extract the text used to generate mathjax expression
(both inline and block display modes) as well as remove all the cruft
that mathjax is adding in the DOM.
Internal ref - t/135307
By default, iOS safari will automatically zoom into focused inputs with
font-sizes less than 16px. To avoid this, we had a CSS rule to ensure
inputs always had a large font-size on iOS. This worked, but did lead to
design inconsistencies.
Instead, we can set `user-scalable=no` on the viewport meta tag. Since
iOS 10, this property doesn't actually stop users zooming. But it *does*
still prevent the automatic zooming of inputs. So it solves our zoom
problem, and allows us to remove the CSS font-size workaround.
ff815384 introduced a modifier which changes tracked state. If the
conditions are correct, this can cause an infinite re-rendering loop.
One example is [here](https://meta.discourse.org/t/346215/4), although
there are other non-dev-tools things which could trigger this kind of
loop. As a general rule, modifiers should not change tracked state.
This commit changes the approach to match the rest of the new-post-menu
assumptions: instead of trying to modify `collapsed` at runtime, the
rendering of individual buttons has the `>1` logic. That matches the
existing logic
[here](https://github.com/discourse/discourse/blob/89ff7d51e6/app/assets/javascripts/discourse/app/components/post/menu.gjs#L392C18-L394C6).
One of the big advantages is a nicer menu on mobile.
This commit also fixes a bug where the close modal action was called for any destroyed d-menu trigger, even if this specific menu was not expanding, which means it was closing a different modal than its own modal, given we can only have one modal at a time.
When the user selects “Use Current Timezone” on Profile -> Preferences
-> Profile, a call is made to `moment.tz.guess()`.
https://momentjs.com/timezone/docs/#/using-timezones/guessing-user-timezone/
states that, by default, previously cached responses from this function
will be returned upon subsequent calls. If your physical location has
changed, this may result in a cached value being returned, and thus the
timezone seemingly not being updating.
By passing the `true` value to the function, the cache is bypassed,
forcing an explicit recheck of the current timezone.
In a PM, if a user has made a post, and is later removed from the PM, they can still edit their own post. This can be done either if they happen to have a composer open in an active tab, or by just manually sending an HTTP request.
The post guardian is missing a basic check, can_see_post_topic? when we determine whether a user can edit a post or not. This basic check is already in place when we determine whether a user can see the post in the first place.
This PR adds in the missing check, so that if the user tries to edit their post after being removed, they'll receive a 403.
It also adds a MessageBus message scoped to the affected user and topic when they are removed from the PM, which will redirect them to their inbox. This helps avoid a stale tab where they are still in the PM which they by right can now no longer see.
discourse-emojis is used in chat only for message actions to show a
difference with the the other emojis so people don't think it's just the
smiley emoji.
When trying to insert schemaless or relative links using the "insert
hyperlink modal" in the composer, the resulting link would be wrongly
prefixed with "https://"
This is a small clean-up PR that does the following:
- Convert api-keys.hbs to a RouteTemplate backed api-keys.gjs.
- Move the sub-page templates (index, show, new) into /api-keys sub-directory.
- Removes some styles that aren't used after the admin UI conversion.
Similar to the `home-logo-href` and `home-logo-image-url` transformers,
this PR adds a new `home-logo-minimized` transformer to allow
plugins/themes to amend the default behavior of the header logo.
Internal topic: t/144688.
The new site setting `allow_anonymous_and_tl0_to_flag_illegal` allows
tl0 users to flag illegal content. In addition, anonymous users are
instructed on how to flag illegal content by sending emails.
Also `email_address_to_report_illegal_content` setting is added. If not
provided, then the site contact email is used.
Reverts 02113fc.
This is an imperfect detection of tablets and more generally, we want to
move away from detecting specific devices. THere's a broader effort to
remove mobile/desktop detection and rely instead on viewport-width-based
patterns and feature detection (touch, hover, etc.). See
https://github.com/discourse/discourse/pull/30642
To reach the same results in CSS/jS, we can use the `touch` and `hover`
media queries.
In CSS, something like:
```
@media (hover: none) {
// hover non excludes touchscreen desktops
.discourse-touch {
// we detect touch capability on the JS side, a bit of a belts and suspenders approach
}
}
```
And in JS:
```
this.capabilities.touch` plus `window.matchMedia("(hover: none)").matches
```
When tapping something on a touch-enabled device, `mouseMove` events are
still fired, so floatkit would still be triggered even if configured for
'hover' only. For links, this would be particularly strange, because the
tooltip would appear for a split-second, before the page navigation
occured.
To avoid this problem, we can use the more-modern 'pointerMove' event,
and check the `pointerType` to exclude 'touch'
* Fix tabbing inputs on first wizard step, the user would end up on
"Skip to content"
for the page "behind" the wizard. If the wizard is showing we can just
not render the skip to content element
* Only show the required wizard steps in the counter, so we do X/4
rather than X/6 at the top of the page.
* Change to "Setting up your theme..." by default, but if the install
takes 10s or more add a note that things are still happening and to
be patient.
Admin pages that are based off the customize or plugin templates were wrapped in the `admin-container` class, which has slightly different margins to the `admin-config-page` class, which is used on most admin pages.
This change ensures that all the admin pages have the same alignment.
Update the header of the admin Logs page to be more consistent with the rest of the admin UI.
The tabs to access the different sub-pages have also been updated.
The heading role on topic lists is desirable for screenreader users
because they can easily navigate from heading to heading.
Having this role on the link tag directly becomes problematic for Voice
Control users on Apple devices because unfortunately Voice Control
assumes that when given the role of a heading, it is not a link. This
makes it difficult to click.
This PR moves the heading role to the link's wrapper. This change allows
for heading-to-heading navigation for screenreaders, and also makes it
easier to click using Voice Control. The end result is that topic lists
are both navigable for screenreaders and Voice Control users.
* Do not offer "categories with latest" option anymore, it does
not look good with our default Sidebar selection
* Display a sensible item in the dropdown if the admin has not
chosen hot, latest, or category_boxes as the homepage style,
before it was broken. Now we show Custom with a little blurb
about whether topics or categories are shown, and what the landing
page is
Update the header of the admin Email Style page to be more consistent with the rest of the admin UI.
The HTML/CSS tabs have also been updated, which required an extra check being added to the NavItem component.
There are a few changes here to make the Emails admin page more consistent with the rest of the admin UI.
- The header and navigation menu have been updated.
- The sidebar now stays highlighted when visiting the email admin sub-pages.
- Moved the Template editor from /admin/customize/email_templates to /admin/email/templates, so it fit as a sub-page.
- Removed the link to the Template editor from the Customize section of the old top menu, since it's accessible from the Emails section, instead.
When clicking the "new features" notification item for
admins that navigates to /whats-new, the user notification
menu was not closing. This was happening because inside
the UserMenu::Menu component, the `routeDidChange` event
was firing and calling `closeUserMenu()`, however this is already
called inside the `Header` component via `toggleHamburger()`.
This is _only_ happening for the "new features" notification
item, other items have already been destroyed and they do not get
the `routeDidChange` event. No idea why, but this fixes the issue
in a global way.
