When we switched to delegated event handling, the bound handler for
all of our events was #main_div, but the floating recipient bar lives
outside of #main_div. Additionally, the bar needs to inherit the zid
from the target recipient bar since it is used for the narrow.
(imported from commit 7c18e16f2e98436888a8edb81fbbdd4d17abfe2a)
The problem seems to be caused by a bug in Firefox. We work around
the issue by adding empty table rows to the top of the table and
removing them when the user is idle.
This resolves trac #413
(imported from commit 2b15a4a2241bd7e813800a42608d650e0d4fa4f0)
I'd like to think about how to polish aspects of this a bit more,
but would like us to be able to deploy master at some point today.
This is basically the philosophical equivalent of reverting the
user-visible UI changes introduced in
b7b6794ad635ec63269a2043cd48b02749fbffda
(imported from commit edfaadf26741c47120c3acf6c410d33025c0a260)
Previously, it was impossible to narrow to a completely empty narrow.
Now it is possible, and the code needs to be tweaked in a few ways
not to break in this case.
(imported from commit e4dd4159ad52d003fc11d0b8b6531322c12a3de8)
Fixes#396.
We could display an error message, but jumping right to the login page seems
smoother and conveys the same information.
This will discard any message being composed, but preserving it would have
security consequences that we should consider further before implementing that.
Hopefully, users only get logged out by an explicit action, so they can't
complain too much (but see #217).
(imported from commit aaa23ecf46c73e514117ae1010fc44e133f2ba07)
Previously, we were adding those narrowed messages to message_dict the
first time, and thus totally skipping those messages each additional
time you tried to "load old messages" on that narrow.
(imported from commit 77eef376e1165b86e3c599608a1b5089a09d51e0)
Sometimes messages are delayed passed the allowed 10 seconds. We may
eventually decide that that amount of latency is unacceptable, but the
latency is not what this script is supposed to be checking.
(imported from commit d83a6a83d60e9eac13b3b87fb31de7f9881acabf)
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)
Jessica McKellar
Luke Faraone
Tim Abbott
Zev Benjamin
Waseem Daher
Keegan McAllister
Jeff Arnold