Commit Graph

14 Commits

Author SHA1 Message Date
Tim Abbott 8b55a310f1 typing: Fix invalid typing notifications for stream messages.
In e42c3f7418, we made the assumption
that compose_pm_pill.get_recipient() would return no users for stream
messages.  It turns out, due to the confusing name of
compose_state.recipient (which we just renamed to
compose_state.private_message_recipient), this assumption was wrong.

As a result, when composing a stream message using the reply hotkeys,
we'd end up sending typing notiifcations to the person who sent the
message we're replying to as though a PM was being composed.

We fix this by avoiding passing an (expected to be unused) value for
private_message_recipient to compose_state.start.
2019-12-02 09:31:16 -08:00
Anders Kaseorg 28f3dfa284 js: Automatically convert var to let and const in most files.
This commit was originally automatically generated using `tools/lint
--only=eslint --fix`.  It was then modified by tabbott to contain only
changes to a set of files that are unlikely to result in significant
merge conflicts with any open pull request, excluding about 20 files.
His plan is to merge the remaining changes with more precise care,
potentially involving merging parts of conflicting pull requests
before running the `eslint --fix` operation.

Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2019-11-03 12:42:39 -08:00
Greg Price 71596648c2 typing_status: Switch sentinel "recipient" value to `null`.
This feels a bit more semantically appropriate: it more clearly says
"here's some information: there is no (relevant) recipient", rather
than "no information available".  (Both `null` and `undefined` in JS
can have either meaning, but `undefined` especially commonly means
the latter.)

Concretely, it ensures a bit more explicitness where the value
originates: a bare `return;` becomes `return null;`, reflecting the
fact that it is returning a quite informative value.

Also make the implementation more explicit about what's expected here,
replacing truthiness tests with `!== null`.  (A bit more idiomatic
would be `!= null`, which is equivalent when the value is well-typed
and a bit more robust to ill-typing bugs.  But lint complains about
that version.)
2019-10-24 14:56:56 -07:00
Greg Price a191890213 typing_status: Fold `stop` into main method `update`.
It'd already been the case for some while that calling `stop` had the
same effect as calling `update` (previously `handle_text_input`) with
a falsy recipient.  With the API changes in the previous few commits,
this becomes quite natural to make explicit in the API.
2019-10-24 14:56:56 -07:00
Greg Price e639b0a6f8 typing_status: Write jsdoc for main entry point, and rename.
This was named after when it gets called from the UI, rather than
after what it can be expected to do.

Naming it after what it's meant to do -- and giving a summary line to
expand on that -- provides a more helpful semantic idea for reasoning
about the function.  Doubly so for using the function in a different
client with its own UI, like the mobile app.
2019-10-24 14:56:56 -07:00
Greg Price dcb5bb7914 typing_status: Combine two parameters into one, with a maybe-type.
The main motivation for this change is to simplify this interface
and make it easier to reason about.

The case where it affects the behavior is when
is_valid_conversation() returns false, while current_recipient
and get_recipient() agree on some truthy value.

This means the message-content textarea is empty -- in fact the
user just cleared it, because we got here from an input event on
it -- but the compose box is still open to some PM thread that we
have a typing notification still outstanding for.

The old behavior is that in this situation we would ignore the
fact that the content was empty, and go ahead and prolong the
typing notification, by updating our timer and possibly sending a
"still typing" notice.

This contrasts with the behavior (both old and new) in the case
where the content is empty and we *don't* already have an
outstanding typing notification, or we have one to some other
thread.  In that case, we cancel any existing notification and
don't start a new one, exactly as if `stop` were called
(e.g. because the user closed the compose box.)

The new behavior is that we always treat clearing the input as
"stopped typing": not only in those cases where we already did,
but also in the case where we still have the same recipients.
(Which seems like probably the common case.)

That seems like the preferable behavior; indeed it's hard to see
the point of the "compose_empty" logic if restricted to the other
cases.  It also makes the interface simpler.

Those two properties don't seem like a coincidence, either: the
complicated interface made it difficult to unpack exactly what
logic we actually had, which made it easy for surprising wrinkles
to hang out indefinitely.
2019-10-24 14:56:56 -07:00
Greg Price dcccef9b3a typing_status: Make some test cases slightly less artificial.
All these cases are meant to simulate having a user actually typing a
message to some actual recipients, so the `conversation_is_valid`
parameter would be true.

We make this change so that in an upcoming change that eliminates this
parameter, the adjustments to the test cases can be highly regular and
we don't have to introduce a new wrinkle to correspond to these values
being false.
2019-10-24 14:56:56 -07:00
Greg Price 5c220ed11a typing_status: Use parameters for data rather than callbacks.
The real purpose these two callbacks serve is exactly what an ordinary
parameter is perfect for:
 * Each has just one call site, at the top of the function.
 * They're not done for side effects; the point is what they return.
 * The function doesn't pass them any arguments of its own, or
   otherwise express any internal knowledge that doesn't just as
   properly belong to its caller.

So, push the calls to these callbacks up into the function's caller,
and pass in the data they return instead.

This greatly simplifies the interface of `handle_text_input` and of
`typing_status` in general.
2019-10-24 14:56:56 -07:00
Greg Price a63786ac0d shared: Set up a way to share some frontend code with the mobile app.
This adds the general machinery required, and sets it up for the file
`typing_status.js` as a first use case.

Co-authored-by: Anders Kaseorg <anders@zulipchat.com>
2019-10-17 16:48:23 -07:00
Anders Kaseorg a3475b422d typing_status: Convert to ES6 module.
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2019-10-17 16:48:23 -07:00
Priyank Patel b70bd6be30 tests: Add tests for the logic of typing_status.handle_text_input.
This tests was added to make sure we catch subtle bug related to
comparing new_recipient and current_recipient. When we changed the
recipient to use arrays instead of string to use new user IDs based
api we encoured this bug and out testing suite couldn't detect this.
2019-06-06 19:56:24 -07:00
Steve Howell 42435db492 Add run_test helper for individual tests.
This run_test helper sets up a convention that allows
us to give really short tracebacks for errors, and
eventually we can have more control over running
individual tests.  (The latter goal has some
complications, since we often intentionally leak
setup in tests.)
2018-05-15 08:24:44 -07:00
Steve Howell c3b89845c9 node tests: Use zrequire in typing_status.js. 2017-11-08 12:24:17 -08:00
Steve Howell 642be6ad18 Revamp state tracking for outbound typing indicators.
This change moves most of the logic related to starting and
stopping outbound typing indicators to a new module called
typing_status.js that is heavily unit tested.

While this was in some sense a rewrite, the logic was mostly
inspired by the existing code.

This change does fix one known bug, which is that when we
were changing recipients before (while typing was active), we
were not stopping and starting typing indicators.  This was
a fairly minor bug, since usually users leave the compose
box to change recipients, and we would do stop/start under
that scenario.  Now we also handle the case where the user
does not leave the compose box to change recipients.
2017-03-22 07:01:20 -07:00