When deduplicating account usernames for OAuthable users, the routine did check if any account was known with that username, including remote accounts. This caused some unnecessary deduplication, and usernames ending with unexpected trailing _1.
This fixes#13580
* Move .back-button inline styles to CSS file
All occurrences of the back-button CSS class used the same inline
CSS rules, so moved them over to the CSS file
* Fix “Add new domain block” button using inline CSS
* Replace common pattern of inline-styled button boxes by a CSS class
In particular, switching from `float: left/right` to a flexbox with
`justify-content: space-between`. This implied changing the order of
a few HTML tags and adding an empty `div` in one case.
Also removed a `margin-bottom` rule that wasn't needed due to the
margins of surrounding elements.
* Move account admin view inline CSS to CSS file
Fixes#13573
For some reason (I suspect this may be related to focusing the item before it
got drown by the browser), Firefox scrolls to top when bringing up dropdown
menus with pre-selected items.
This commit uses the “preventScroll” option as, due to the placement behavior,
the menu should be visible anyway and not trigger scrolling.
* Move some inline styles to CSS files
* Move default_account_display_name span to fix useless tags with duplicate id
* Change handling of public pages spoiler text from inline CSS to dataset attribute
* Use the `dir` HTML attribute instead of inline CSS
* Move status action bar inline CSS to CSS file
* Hide logo resources from CSS file, not inline CSS
Fixes#11601
* Move translation prompt styling from inline CSS to CSS file
* Move “invited by” styling on registration form from inline to CSS file
* Use the progress tag to display poll results in JS fallback
* Fix poll results JS-less fallback when the user has voted for an option
* Change account public page “moved” notice to use img tags instead of inline CSS
* Move OTP hint inline CSS to SCSS file
* Hide JS-less fallback vote progressbars from accessibility tools
Co-authored-by: Eugen Rochko <eugen@zeonfederated.com>
Attempting to upload image files that the browser is unable to load results
in “Oops! An unexpected error occurred.”
This commit changes the error handling so that an unprocessable image results
in the file being sent anyway, which might cover a few corner cases, and
provide a slightly better error message.
Fixes#13536
- Expanding a paused video doesn't autoplay anymore
- Default volume level for the expanded video inherited from the original video
Position/playing state/volume are carried over from the original video player
to the modal, but they're not reported back to the modal as it would require
deeper changes.
This is achieved by sending a DELETE request to
/settings/profile/pictures/{avatar,header} via a link that is part of
the upload form's hint of the respective picture.
Some browsers (at least recent Chrome versions) automatically take
image metadata into account when drawing images into a canvas.
There seem to be no way to prevent that behavior, and the only
way to detect it seems to compare with a known image.
See: https://github.com/w3c/csswg-drafts/issues/4666
Solution adapted from: 1e4df70782
Follow-up to #13452, fixing broken `uri.nil?` test.
Also remove the separate check for `uri` presence, as that would result
in a “Please review 2 errors below” while only one would be listed.
* Fix “Email changed” notification sometimes having wrong e-mail
Fixes#6778
The root of the issue is that `send_devise_notification` was called before
the changes were properly commited to the database, causing the mailer to
pick previous values if running too early.
Devise's documentation provides guidance on how to handle that[1][2], however,
I have found it to not be working, as the following happens, in that order:
- `send_devise_notification` is called for the `email_changed` notification.
In that case, `changed?` is false and `saved_changes?` is true, so
if we use the former, we have the same issue.
- the `after_commit` hook is called
- `send_devise_notification` is called for the `confirmation_instructions`
notification.
In that case, `changed?` is still false, and `saved_changes?` still true,
so if we use the latter, that second notification email is simply not
going to be sent (as we would be queuing the notification *after*
executing the after_commit hook).
This is because it may be called from either an `after_update` or
`after_commit` hook, the difference not being a call to `save` but the
transaction actually being committed to the database. This may arguably
be a bug in Devise, or Devise's notification.
The proposed workaround is inspired by Devise's documentation but checks
whether a transaction is open to make the call whether to immediately
send the notification or defer it to the `after_commit` hook.
[1]: https://www.rubydoc.info/github/plataformatec/devise/Devise%2FModels%2FAuthenticatable:send_devise_notification
[2]: 406915cb78/lib/devise/models/authenticatable.rb (L133-L194)
* Fix cases when sending notifications without changing the model
* Defer sending if and only if in transaction including current record
ThibG