The server only saves the maximum position the pointer has ever had. So
on reload, it often jumped to the end instead of where the user was.
(imported from commit 418ccb1144286c67503578020e88ae7b3869acd6)
This also normalizes the casing of operators, which makes
Sender:wdaher@humbughq.com work when it would previously give an
"unknown operator" error.
(imported from commit fb3f748a474e1c9c710547ae3c05a4ace86c3230)
Previously, narrowing to a stream also narrowed to
/^(un)*stream-name(.d)*$/, but not the other way around.
(imported from commit 6643f8d8306a737f4e96d473dd1fdbfdcd56e2a8)
Fix a minor bug where if you return to the home view with a recipient
filled out, it would be unfaded.
(imported from commit d81d974dcb054c63d8a5dd5afec7b072c99d4e3f)
Unlike the other cases where we do this sort of offset calculation,
we're working with a message which is not msg_list.selected_id() --
which means that this message might not actually be rendered at all.
Correct for this by just letting then_select_offset stay undefined in
that case.
(imported from commit ebb8a23bf34c52f9495aa88ceca8eb4458d50be1)
This fix also cleans up the search operators so that @-mentions
and Private messages have a more similar naming convention.
(imported from commit fb1a2119aab5aa9e179c6e321a8d2ef2e90290cf)
This is slightly inconsistent, but keeps the unread count from decreasing
when narrowing and un-narrowing.
(imported from commit 185e8653c31a312c166e784b335ae7ae7e9b78e9)
This should substantially improve narrowing performance, while still
delivering enough messages that one should only need to contact the
server again if the user scrolls up a significant distance.
(imported from commit 2b0af0e5b9d3a449e7f195a87d57d517b47f0b3a)
This cleans up most of our blocks of code that assume in any narrow
that the only operators present are the ones of interest and that they
always appear in the expected order.
(imported from commit 038707aefbe125b0c14f823fa93472fd40302e20)
Previously it could return an array or boolean, and this inconsistent
interface had several latent bugs where consumers of the API only
considered it returning one or the other type.
This also fixes a specific bug a user triggered by being narrowed to
nothing (/#narrow) and clicking in the compose box.
(imported from commit 64ca2a37a9f288066f89b0ddec6638e010704eb0)
Re-focuses on the compose box after a send, under these conditions:
1) narrowed to stream+subject -or- responding to PM/huddle
2) compose was initiated by clicking on a message or hitting "r"/"enter"
3) cursor has not moved since you've started the composition
Additionally, if you are thus narrowed, we will move your cursor when you've sent
a message to that message, assuming that such a message initially appears visible.
(imported from commit 373c858081694e6fc9994639340a847d66edb566)
Treat "mentioned" messages like "starred" messages for narrowing.
Lots of ugly copy/paste here. There might be opportunity for
some cleanup in places.
(imported from commit e7629890d42643c0000e1cc85422b2a0690f2cc4)
Most of the model logic pertaining to unread counts had been in
zephyr.js, along with a couple global variables. Now the code
is encapsulated in unread.js. It was a pretty straightforward
extraction with some minor method name changes. Also, a small
bit of the logic had also been in stream_list.js.
Conflicts:
tools/jslint/check-all.js
(imported from commit f0abdd48f26ab20c5beaef203479eb5a70dacfff)
This commit also fixes a bug where "starred messages" wouldn't get
bolded when you narrowed to starred messages. However, it also
introduces a regression where subjects aren't highlighted correctly
on load to a narrow which will be fixed shortly.
(imported from commit 411575d92762e41d04c1baf126c0ab1dfb4225a5)
Messages are now explicitly condensed by our JS, which means that if
we run into some bug where our JS doesn't run, you still see the whole
message (rather than getting a clipped message).
(As of this commit, this can happen when you, e.g. are on the
Settings page and someone sends you a message.)
(imported from commit f3bec97800ea1852c80203e73552ee545fcc7e8a)
Previously, we were having this problem where:
* You narrow to something
* That causes message_list.js:process_collapsing to run on all of the
elements in the view, which changes some of their sizes
* That causes the pane to scroll and either push the content up or
down, depending (since stuff on top of where you were is now a
different size)
* That triggers keep_pointer_in_view, which moves your pointer
Moving process_collapsing into narrow.activate doesn't obviously
fix any of this, but it does seem to mitigate the issue a bit.
In particular, we (a) process it less frequently, and (b) process it
immediately after we show the narrowed view table, which seems to
reduce the raciness of the overall experience.
This does, however, introduce a regression:
* If you receive a long message when you're on
#settings, e.g., and then go back to Home,
the message does not properly get a [More] appended
to it.
(imported from commit b1440d656cc7b71eca8af736f2f7b3aa7e0cca14)
Steve Howell
Kevin Mehall
Jessica McKellar
Allen Rabinovich
Zev Benjamin
Tim Abbott
Jeff Arnold
Leo Franchi
acrefoot
Waseem Daher