* UX: Remove background image after image has loaded
If an image has a `smallUpload`, that may be set as the `background-image` on the `img` element, and the `img` element set to use `lazy` loading. When the browser decides to load the `src` of the image element, it is rendered on top of the existing background image.
However, if the image proper has a transparent background, the background image may be partially visible through the transparent portions of the image.
This change creates an `onload` event that removes the background image when the image proper has completed loading.
Partially revert f490a8d39a because we aren't able to
load more than the initially preloaded voters.
We were always trying to load the 1st page of voters.
Also removed the "remove users who changed their vote" logic as it was not properly working in multiple choices polls.
cc @nbianca
Skip group SMTP email (and add log) if:
* topic is deleted
* post is deleted
* smtp has been disabled for the group
Skip without log if:
* enable_smtp site setting is false
* disable_emails site setting is yes
Co-authored-by: Alan Guo Xiang Tan <gxtan1990@gmail.com>
For other private messages we have the site setting
personal_email_time_window_seconds (default 20s) which allows
people to edit their post etc. before the email is sent.
This PR makes the Jobs::GroupSmtpEmail enqueuer in the
PostAlerter use the same delay.
<!-- NOTE: All pull requests should have tests (rspec in Ruby, qunit in JavaScript). If your code does not include test coverage, please include an explanation of why it was omitted. -->
Since disable_ddl_transaction! is disabled for this migration, it needs to be idempotent. Any error during the migration (e.g. a timeout) will cause ActiveRecord to fail the migration, and try again on the next run. If the index had already been created during the first run, then an 'already exists' error will be raised, with no way to recover.
Unfortunately an [ActiveRecord bug](https://github.com/rails/rails/pull/41490) prevents us from using `if_not_exists: true` alongside `algorithm: :concurrently`, so we have to drop to raw SQL.
Exposes to Ember CLI environment the feature provided in the production env by `lib/stylesheet/manager.rb:295`.
Fixes development env compatibility with discourse-color-scheme-toggle.
This PR changes the order of the topic timer options
into a more logical order when the topic is open/closed.
Also, we are now hiding the "Schedule Publishing" option
if the topic is not a private message or in a private category.
It does not make sense to schedule publishing to a different
category for a public topic.
This is just a hunch, but this is quite a complex test.
I think that there is some timing issue where the jobs
enqueued for generating the thumbnails via the serializer
thumbnails method and they aren't generated in time before
we do the json[:thumbnails] check. Split the tests up
into two, with one checking the right jobs are enqueued
and another with Jobs.run_immediately! that checks that
json[:thumbnails] is correct.
We renamed the site setting for this long ago, but there
were a few places left in the code base where "ninja edit"
needed to be turned into "grace period". Doing this here
to avoid combatative language.
* FIX: Detect decode failures earlier in image optimization pipeline
Follow up to 9b51b9b but also detects the bug earlier and backs off.
What iOS 15 is doing is returning all zeroes to `ctx.getImageData`,
so we don't have to wait until resize to detect the problem.
* Update app/assets/javascripts/discourse/app/lib/media-optimization-utils.js
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
On iOS 15 beta, if you select the camera app when uploading an image
and try to upload a freshly taken picture, from the second picture
onwards the resize WASM operation will return an array filled with
zeroes.
Since every 4th byte is alpha, and at this step we are only dealing with
non-transparent images this a O(1) way to detect that the bug was hit.
(On normal images, all 4th bytes are 255 at this point)
Also adds a "catch-all" when the original image became too small to try
to accomodate other bugs of the same type. By default we only trigger
this whole operation on images over 1MB, so if the end result is <20KB
something weird did happen. Throwing here will let the upload continue
using the original file, so nothing is lost and the user can continue.
We want to put the name of the trust level in to generated URLs, not the human-readable form.
i.e.:
`/admin/users/list/newuser`
rather than:
`/admin/users/list/new user`
