Just for the record, here's what happened:
If you click on a class message to start a reply, then click outside
to unfocus, then click on a huddle message to reply to that instead,
the system would end up calling the focus handler twice and _then_ the
unfocus handler once (why are we unfocusing something? Because we
have two compose windows -- new_zephyr and new_personal_zephyr, and
we're switching between them). the end result is that we'd re-enable
hotkeys with that unfocus handler.
Fix this by being sure to explicitly disable hotkeys after we setup a
reply to a message.
(imported from commit a7735d9a63f0c3c9f6c12d94e8bb107bf3675f44)
This essentially reverts commit 0d6c3e4d0a70e06b9b2f6e5830b3a9650e44441a,
though also adds support for this behavior with the 'j' key.
(imported from commit 36c51e0f6bd03c53b84abddc75097cb06fc04e16)
(It's not totally beautiful, though, in that it causes
your timestamp to appear in a weird place, but it's
better than the alternative.)
(imported from commit 217b6545330f7850f2892df2e82df18976463361)
Previously we triggered all hotkeys on keydown. Now, if the keydown event
is in the range of a character we bail and wait for it to be handled by the
keypress function instead.
We also redefine all of the keycodes for characters to be their lowercase
versions.
(imported from commit 534199de92174c2858220abb21ce774e1ee0e1d3)
This is somewhat experimental and we may need to work on the condition
when it shows up (or move it elsewhere).
Also, maybe it should say "Today/Yesterday" for times super close to
now -- the main issue with doing this is whether it needs to update
without your reloading the page to avoid being super confusing.
(imported from commit e29faf30c83b9574e5d233213f42a24175f9a616)
This actually is a bit cleaner than our last approach,
because (I believe) we run our scroll handler code
even after the final scroll event, which prevents the
pointer from getting hidden by rapid scrolls.
(imported from commit 3bde4e8f067cd2406f90c04425c6e4ffb81ea784)
The issue was that our 'button' was actually a link with href='#',
and we didn't actually cancel the event; so it jumped to the
top of the page.
(imported from commit e66decb3a202ea22176ec539a1ec1d405faf0117)
This keeps the pointer in the middle 3/5ths of the screen and
asymmetrically handles going above or below those bounds.
(imported from commit 9a6033f53365e6d6cd8f82eb096af849e3b22542)
I'd like it to ultimately be the case that if you make the window
too narrow, the menubar goes to the very top and has small icons.
(imported from commit 0a5fe548d4d848c0358c9780df7af1fe1abc93fa)
Try to adhere to Bootstrap grid system a bit more consistently.
Unstyle subscriptions page for consistency.
Still not sure why the "affix" jumps when we switch to "Subscriptions."
(imported from commit 1c28de4e2ef3d6ed3d1bdcfd143eadefba2b46cb)
It causes problems when [un]narrowing, and we already do the rest of formatting
on the server side.
This reverts commit 90af0192b37bbebbf56d5e7c50f182485ddbca10.
This reverts commit df7e355648d2c4d6319de049933547ed96402fd8.
(imported from commit 99d87f0826ec2f49741f86fad6524ed93e76723f)
This broke the test suite, which expects all settings to exist in this file. Whoops.
This reverts commit e4108333c53afb0caf55348837b739cb7e5510dd.
(imported from commit e6b58004059e834d4e30ea9c63463eb84179cc1e)
When you're at the top of the page, you don't get scroll events
anymore if you're scrolling with a mousewheel. So we need
to listen to mousewheel as well as scroll.
(Why not *just* mousewheel? Because then the scrolling done by
PageUp and PageDown no longer causes the pointer to refocus,
because those trigger scroll events.)
(imported from commit 4ee23004f6e090abaabb836f0a9d7b59d0394ced)
There still seems to be some glitching when arrowing around,
which still needs some investigation.
(imported from commit 9c4d8f2b0b55fda5077e2fba70cbe4bcd50b823a)
This code is the start of something that would make your
narrowed-on message remain in the same place post-narrow,
which is possibly a good idea.
(imported from commit 0a557d6492de470928245b33f95ae8c0102db0a6)
I believe we'll get this for free with the new version of
select_zephyr and our bottom_whitespace div.
(imported from commit 0d6c3e4d0a70e06b9b2f6e5830b3a9650e44441a)
scrolling-tab used to be used to target which tab would be a recipient
of the scroll events generated by PgUp, PgDn, etc. Since we now let
the browser handle these natively, we don't need to worry about it.
(Instead, when we hook the 'scroll' event, we should make sure that
home screen.)
(imported from commit c555d960da995a09b370867c96d17f4ce4f2171f)
It turns out it's marginally easier for us to completely handle Home
and End ourselves rather than let the browser do it, because home
scrolls to the top of the page, but it does not select the topmost
message.
With PgUp and PgDn, the default browser behavior is fine,
but it seems like PgUp on a screen where you're already
"scrolled to the top" should not be a no-op.
(imported from commit 609d639f3a4313e75e1fd6138966f15447b70f2e)
This causes #home to expand to contain it, which is great because
now we can bind to things like "click" or "scroll" or "keydown"
that are in #home.
(imported from commit 3efe95a7a96f7aee9983369848bf9e7210e00c66)
Tim Abbott
Waseem Daher
Jessica McKellar
Luke Faraone
Keegan McAllister