The original "quality score" was invented purely for populating
our password-strength progress bar, and isn't expressed in terms
that are particularly meaningful. For configuration and the core
accept/reject logic, it's better to use units that are readily
understood. Switch to those.
I considered using "bits of entropy", defined loosely as the log
of this number, but both the zxcvbn paper and the linked CACM
article (which I recommend!) are written in terms of the number
of guesses. And reading (most of) those two papers made me
less happy about referring to "entropy" in our terminology.
I already knew that notion was a little fuzzy if looked at
too closely, and I gained a better appreciation of how it's
contributed to confusion in discussing password policies and
to adoption of perverse policies that favor "Password1!" over
"derived unusual ravioli raft". So, "guesses" it is.
And although the log is handy for some analysis purposes
(certainly for a graph like those in the zxcvbn paper), it adds
a layer of abstraction, and I think makes it harder to think
clearly about attacks, especially in the online setting. So
just use the actual number, and if someone wants to set a
gigantic value, they will have the pleasure of seeing just
how many digits are involved.
(Thanks to @YJDave for a prototype that the code changes in this
commit are based on.)
We now return user_ids for subscribers to streams in add-stream
events. This allows us to eliminate the UserLite class for
both bulk adds and bulk removes. It also simplifies some JS
code that already wanted to use user_ids, not emails.
Fixes#6898
This function was extracted from build_user_sidebar(). We
also slightly streamlined it to not unnecessarily call
filter() when the filter text was blank. This extraction
also eliminated the need for us to have the two-line
filter_and_sort() function.
Also, we get to 100% coverage in this commit.
We now intialize user-list-filter within activity.initialize(),
which gives us more control to set the module variable
`meta.$user_list_filter` before we build the user sidebar,
while setting up its handlers after we build the sidebar.
We've been getting reports for a few months of folks coming back to
their Zulip window after a night's sleep and finding it scrolled to
the bottom, past dozens or hundreds of messages that they haven't
read. Oddly, the pointer is actually still located where it should be
(verifiable by hitting the Up key), but it's too late: everything
below gets marked as read because bottom_whitespace is in view.
There's only a few places in the zulip codebase where we scroll the
page down, and this is the main one of them. My best theory for what
could be happening is that the browser is, in its overnight
power-saving mode, not granting the Zulip window the resources to
actually repaint the early scrolls. This, in turn, would cause
scrolling down to happen that is not limited by the need to keep the
pointer in view.
I don't think that this fully closes the issue; ideally, we'd have a
reproducer and much more precise detection logic for this situation,
but it should mostly resolve the problem with likely no user-facing
visible harm.
Previously we used to mark a key as unstranlated if its value was equal
to it in translations.json. This had an issue because it didn't allow
otherwise valid cases where key was equal to the value.
This commit solves the problem by disallowing an empty string as a valid
translation and then using the empty string as the value for all the
unstranslated keys.
Fixes#5261
Currently when hovering on an emoji it will focus it, which makes
the browser by default scroll down or up to include the entirity
of the focused element. This corects the scrollTop to what it was
before the focus event adjusted the scroll position.
This is a follow-up to #6869.
Previously, you had to hover over the smaller area where the emoji
image was to select it, whereas the user expectation is that hovering
the emoji's padding should select it as well.
This commit makes the arrow key navigation and mouse hover affect the
same state such that for example if one moves the mouse over some emoji
and then hits down-arrow the cursor will move down by one from where he
left the mouse at rather than beginning from the top-left corner.
Fixes: #6827.
This will look through all users and not just ones active in the last
three weeks but only when you are searching with the right sidebar
input box.
Fixes: #5775.
This tries to toggle the next item when clicking on an <h2>
in the sidebar, however we want to first check the next item is
an <ul> element, so that we are collapsing or showing a list,
instead of something like an <h2> which currently happens with
the "#guides" element.
The `have_scrolled_away_from_top` logic goes way back
to November 2012.
Now we unconditionally load older messages when we scroll
to the top of the feed. Before this bug, you could get
"stuck." It was a bit difficult to reproduce, but with
the right combination of render window sizes and batch
sizes, you would hit the home key quickly and hit the top
of the feed in a way that the flag got in the way of
going back in history.
Fixes#6628
We had a bug where once you scrolled back far enough
in the message view, your "window" for rendered messages
would be at the max, and `prepend` was not adjusting
the window correctly. Now we follow the example of
`append` and call `maybe_rerender`.
This partially addresses #6628, where users were
reporting that the home key stopped going up in their
feed. There was another bug at play for that issue
as well, which is fixed in the next commit.
Before this, the home key would go to the first message in our
render window. Now we go to the first message in our local
list of messages. (Note that there may still be older
messages, so it will still often take multiple uses of the
home key to truly get to the top of your feed.)
In the refactoring in 31d3b1ecc0 that
fixed live-updating of the medium-size avatar data, we started just
fetching the normal-size avatar, not the medium-size avatar. We fix
this by changing this code path to pass in the user object and
construct the URL using that.
While we're at it, we switch to using the user ID, not the email, to
construct these avatar URLs.
Previously, we relied on fetching the name of the user from the data
attributes on the individual elements, when we can get a more reliably
up-to-date value from the people.js data structure we're fetching
anyway.
"Mobile push notifications always" is now indented and a
sub-setting of "Mobile push notifications when offline".
It can be selected only when the outer setting is
selected, otherwise it is greyed out.
Fixes#6570.
We've iterated on this code incorrectly something like 3 times now, so
it's worth rewriting it with a lot of comments in a way that makes
sense.
The main actual functional change here is that modified key + enter
now is consistently the opposite of enter (in terms of whether to
provide a newline or send the message) in all cases.
Fixes#6489.
