In get_display_recipient, the userprofile was selected incorrectly by
user_id instead of the userprofile_id. In production, this hasn't
resulted in a user-visible error because we use MySQL and user ids are
always equal to userprofile ids.
This does happen if you are using SQLite locally and run populate_db,
which adds a bunch of users in parallel in an insufficiently
transactional way.
(imported from commit c25a04b4919e3efdfc6996b03492f7714d9034e8)
This bug affected receiving messages while narrowed. When none of
the messages recieved matched the narrow predicate, we'd try to
render messages and then create a jQuery object out of a bunch of
newlines (the only thing that results from a render of 0 messages).
(imported from commit 81f5aa46fac06fe0e5a14a8757f245f90b5845cc)
This greatly reduces the number of events generated and prevents the
blue flashing on message arrival.
This also necessitated a change in how we looked up message rows to
add the 'next_is_same_sender' class, which led to a further
optimization where we don't have to do as many jQuery selections by
id.
(imported from commit 0bcd5688b483c560b6f3a29c6d36433da600e8ef)
And wire it up to our local copy of codehilite. This fixes highlighting in
fenced code blocks, e.g.
~~~~ .js
var x = function () {
return "hi";
};
~~~~
(imported from commit 0efb0c9b98a3acdf55e18bb1918af7960f3425be)
In particular:
* Taking a list of streams as arguments.
* Using the _backend model so that we can have an API version.
* Considering "not subscribed" to be a non-fatal error.
And of course the corresponding changes to subs.js.
(imported from commit fdb300c6aa6921c2c6b09c22bd1e64405c368809)
One way this can happen is if run-dev.py --test is already running. In that
case the one we launch will die with "Address already in use", and we should
alert the user that test results may not be accurate.
(imported from commit 078091cace2cff777b444668b03f96dc208f22fc)
This should address the catherio/tibbetts feedback of the name
breaking oddly across the middle of their name.
One notable change introduced by this commit is: If your name is very
long, e.g., "Waseemio Daherioian", it gets cut off. (On Firefox, it
gets rendered as "Waseemio Daherioia...", and on Chrome it gets no
ellipsis at all.)
The current behavior is that the long name actually overflows into
the main text area, which I think is worse.
(imported from commit 668cb30bc2326c255b229f4f19f29be473bdc1e8)
The existing code shortens the searchbox each time it receives focus.
Unfortunately, this means that if it receives focus twice in a row, it
shrinks twice in a row. (For some reason, the '/' hotkey does this).
So, instead, make it idempotent -- if we're already shrunk, don't
shrink us again.
(imported from commit 8179963bbd00822d15d92609d89f572d2de7800c)
This is nearly perfect, modulo two things:
1. If you have a search active and you resize the window, the search
box resize doesn't take effect until you exit the search.
2. In super-narrow windows (<380px), the searchbox overshoots
the message area slightly.
I don't regard either as huge issues -- I'll probably fix#1
eventually.
(imported from commit 4900fb9783cc9f447315b0892bd3505f5c31ce15)
