On mobile, when you go to our /help pages, you cannot scroll the
sidebar content. As for testing, the bug can be reproduced by
using a mobile display in Chrome inspector. One caveat of this
bug is that if you go to /help with a mobile display toggled,
the scrollbar won't work. However, if you switch between
different mobile displays, it starts working.
This commit adds some JS that sets the right CSS properties
when the hamburger is clicked.
This fixes the following flow being broken:
* You start on
http://zulipdev.com:9991/accounts/go/?next=/upgrade%23sponsorship
(which we link to from e.g. /plans/)
* The form on that page has
`action=/accounts/go/?next=%2Fupgrade%23sponsorship`, i.e. it has correctly
URL-encoded the `next `value.
* You enter a realm name and hit submit.
* That redirects you to
`http://realm-26.zulipdev.com:9991/upgrade#sponsorship`, would is
correct if you are already logged in.
* However, if you're not logged in, `/upgrade` will serve a redirect
to the login page, landing you at
`http://realm-26.zulipdev.com:9991/devlogin/?next=/upgrade/#sponsorship`.
This page works. But in production, it would instead be:
`http://realm-26.zulipdev.com:9991/login/?next=/upgrade/#sponsorship`.
On this page, password login works but social login does not.
Note that the `next=` value is no longer URL-encoded, and thus is
parsed by the browser as `?next=/upgrade` + a hash of
`#sponsorship`.
* If you now login with Google auth, you find yourself on
`http://realm-26.zulipdev.com:9991/#sponsorship` (no /upgrade).
The root cause was that we have a bit of JavaScript in signup.js and
dev-login.js that is intended to handle this; but it was broken for
the social login case for unknown legacy reasons.
This bug appears to date from the original
b62bdde303 which introduced `next`
support for social backends in the first place.
As it turns out, anchor links on headings only worked on our /help and
/api pages but were broken everywhere else. This commit adds the
required JS to scroll properly when an anchor link on any of our
various landing pages is clicked. We already have similar code to
accomplish this in help.js.
We verified with console logging, browser Sources inspection, and
checking source files that help.js and landing-page.js are never
included in the same page, but we add comments to make this
architecture clear.
Fixes#19349.
These modern landing pages cover use cases previously not detailed on
our website. Technically, we had a /for/research page before, but it
wasn't finished or linked everywhere.
Removed "function-url-quotes" stylelint rule
since I need to use quotes in url to use an
svg as list bullet point. There are spacing issues
using it as an image. Also, using quotes in url
is actually the recommended way to do it otherwise
there could be issue with escaping.
A recent PR introduced a bug where navigation dropdowns on the
landing page would not open for tablet/mobile screens. This
commit fixes that issue by using the proper media query to
differentiate between touch and mouse-based devices.
This commit restructures the top-level navigation on our landing
page using dropdowns in a manner that allows us to advertise some
important pages to our visitors:
- Use cases for companies, open source projects, and communities.
- Miscellaneous pages about the product are now accessible from the
"Product" dropdown.
- "Resources" are a few key resources our users may want to consult
if they need help or support.
This commit disables the button and shows a loading spinner on
the button when signup request is being processed to avoid race
conditions caused by user clicking on the button multiple times.
The fix is done observing that for the case when form is invalid
the whole page is rerendered and thus we do not need to remove
the spinner and enable the button again and for other errors
we redirect to some other page.
And for the validation taking place in client-side, the button
is disabled and spinner is shown, only is form is valid, by
using "$('#registration').valid()".
Leave the Intel build as the prominent default, since it will run on
both platforms. (I would have liked to detect the appropriate
platform, but Apple seems to have put significant effort into making
that impossible for anti-fingerprinting reasons, which is probably an
overall good.)
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Due to spaghetti CSS that should be fixed but isn’t fixed here, the
<span> wrapper is still needed so the hover effect is applied.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
In the source realm selector, when we select a realm from which we want
to import the data, we pass the source realm's string_id. The problem
with this approach is that the string_id can be an empty string. This
commit makes the source_realm pass the realm's id instead of string_id.
Now, the source_realm's value will either be an integer or "" (empty
string) when we don't want to import settings from any realm.
The show password feature is a functionality to
toggle the visibility of the password fields in forms
so that one can check if they have entered the correct
password or not. We implement this using an eye icon
toggling which converts input field type from password
to text and vice-versa.
Fixes part of #17301.
This reverts commit a00f5dd90e (#17801).
That commit introduced a regression in the portico pages as described
in commit 85b3157b47. Since that fix
introduced a regression of its own, we need to revert both commits for
now.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Replaced methods/functions of moment.js with date-fns library.
The motive was to replace it with a smaller frontend timezone library.
Date-fns ~ 11.51 kb
moment.js ~ 217.87 kb
Some of the format strings change because date-fns encodes them
differently from how moment did.
Fixes#16373.
Eeshan Garg
Tim Abbott
Aman Agrawal
Priyank Patel
sahil839
Anders Kaseorg
Siddharth Asthana
Gaurav Pandey
PIG208
aryanshridhar
Anders Kaseorg
Vishnu KS