The CLI options offered by the jdenticon library doesn't
include option to configure lightness range of colored and
grayscale shapes.
The npm package itself has options to configure these, but
not exposed via CLI tool.
This commit makes changes to add the following two options:
* --lightness-color
* --lightness-grayscale
Signed-off-by: Prakhar Pratyush <prakhar@zulip.com>
This commit adds support to use Jdenticon to generate avatar,
if user's avatar source is configured so.
The avatar is generated using Jdenticon's NPM package and
stored locally or to S3.
When realm's default_avatar_source is set to Jdenticon,
user's avatar is generated using Jdenticon in the following
cases:
* New user created
* User deletes their uploaded avatar image
* Imported user with no user-uploaded avatar
Fixes part of #36522.
Signed-off-by: Prakhar Pratyush <prakhar@zulip.com>
This commit adds code to resize the image after cropping in
the client itself to the maximum allowed dimensions. If the
cropped image is already within the maximum dimension
limit we do not do anything.
We do this resizing in server, but we need to do it in client
as well to make sure that we do not upload a very large image
file which can happen after image being encoded to PNG after
cropping.
When pasting a large amount of text (>5k), pasting in compose is
noticeably slow due to `update` event in `autosize` causing
layour reflows since it is called thousands of times during a paste.
To fix it, we throttle the `update` event to only run once every
50ms by default.
This is a big bang commit that combines the
GIPHY picker UI with the custom grid implementation
and completely removes the existing third party
component.
We introduce the GiphyNetwork class as a part
of this commit.
We, also rename some of the CSS classes that would
have otherwise broken the behavior of the GIPHY
picker if done in previous commits.
We rename `tenor.ts` to `gif_picker_ui.ts` and
introduce a `provider` state variable for some
conditional logic in `toggle_picker_popover`.
Signed-off-by: apoorvapendse <apoorvavpendse@gmail.com>
We are using browserslist-useragent-regexp to build a regex to compare
our user agents against. This regex is generated and stored in
web/generated and is generated on every provision. This will remain
mostly unchanged since .browserlistrc is not a frequently modified file.
Still, we run it on every provision since we don't have a good mechanism
to detect changes in that list. We can look into that in a followup PR.
In terms of chosing the library, the regexp library is the current
recommendation browserslist github. Another library called
browserslist-useragent exists but it is not actively being worked upon
and is slower as well:
https://gist.github.com/dangreen/55c41072d8891efd3a772a4739d6cd9d
In terms of which browsers to flag as unsupported, we don't flag any
browsers that are not part of >=0 % query of browserslist. If they are
part of >= 0 %, but not part of `baseline widely available with
downstream`, we flag the browser as unsupported.
We also allow higher versions while generating the regex, so if our
regex is outdated a little bit, users with newer browsers don't get the
unsupported browser warning.
I wrote time_zone_util before date-fns 4 was released with time zone
support. (There was a separate date-fns-tz, but it didn’t handle
daylight saving time correctly.) Now we get to replace it.
https://blog.date-fns.org/v40-with-time-zone-support/
Signed-off-by: Anders Kaseorg <anders@zulip.com>
We also make sure that /help/ is accessible when using the dev server.
We add vite as a dependency. v7 of vite is the latest version but using
that causes type problems for PluginOptions since astro uses vite v6.
Therefore we pin vite to v6 for now.
This commit also runs `pnpm dedupe` for `tinyglobby` pinning it to
0.2.15 instead of the previous 0.2.14 in the lockfile.
Even though we have separate packages for `help-beta`, we have opted to
put the prettier plugin and config for astro files in the main project
itself, so that linting needs to be configured only at one place.
This commit fixes a bug where uploading the same file a second time
in the same browser session would appear to the user to stall with
`Uploading [filename]...` in the composebox. This is because
`tus-js-client` makes a HEAD request to check for already-uploaded
files -- and, if found, that request is used in the `upload-success`
callback. That left the callback with no response body to parse, to
know what URL to insert.
Store the `/user_uploads/...` URL in the file metadata after a
successful upload, and if the fingerprint matches a previous upload,
pull that URL (and filename, as it may have changed server-side) out
of the previous upload's metadata.
Co-authored-by: Shubham Padia <shubham@zulip.com>
