Rather than trying to keep track of whether the last thing that
happened was an input area being focused (which had all kinds of
bugs), just detect whether we're in an input area using the
appropriate jquery selector. Hopefully this has OK performance.
(imported from commit 6150692ffcb0ab9b04244c3d053b5527847ded2d)
It is confusing, and clicking on it should behave like clicking
elsewhere in the message.
(imported from commit e56434e8e143f6fa58b095e1c7d311b4aa24313f)
The new version is now the only codepath that we use in order to start
a reply to a message.
(imported from commit dd28316d2640fd5fd712f326690d480b7db59c4c)
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 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)
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)
Tim Abbott
Jessica McKellar
Waseem Daher
Luke Faraone
Keegan McAllister