Known issues:
* Not all of the options in the menu are functional yet
* The wording isn't totally perfect on some of these options;
I kind of want to use a 'first name' in some of them.
(imported from commit 5a333fb939fcca7e0d0ecb2c43e79501139ac0db)
That andSelf is only necessary if a .recipient_row were immediately
followed by a .bookend_tr, which, I don't know, after a redesign could
very well be the case, so let's guard against it now, especially since
our performance on scroll is currently pretty good.
(imported from commit 1011555fbfd30943b4aa917997d6e35bcce959fc)
I think this'll allow for a slighlty more accurate drawing of our
floating recipient row in the even that some of these things have
borders and others don't.
(imported from commit 31714f7356604e1d9c64bcc7f6fd14b8a02a99b5)
I'm actually not sure if this is a performance gain or not; I guess it
depends if any of the stuff inside mousewheel or scroll took longer
than 50ms to call (and right now it does).
(imported from commit e3fcc4a14cd8787fa2357a43ed878ab08646e4f2)
This allows us to put other stuff in the narrowbox and have
it also magically get resized. At least in theory.
(imported from commit 92975e3d0893b34d52cad910462cbf2ccaed2eab)
There were two issues:
* The people_list population changed and I failed to noticed
* Typeahead source updating never worked before because calling .typeahead()
more than once does not change the data source
(imported from commit fda14029f4cd37260d82e7bb5689f5022e1b0d28)
This also makes the people_list a list of objects containing the person's full name and email.
(imported from commit cff9b3de8cab0c9b2690ffa60d65d666302b989f)
When Bootstrap shrinks the divs down into 'tablet' mode, our selected
message might end up being even lower in the screen than it was before
(because more text wraps). But our scrollbar does not automatically
advance to keep it in view -- so we do it manually.
This implementation is a little hackish in that it does some
unnecessary recenter_view-ing in big views (which can be a touch
disorienting) to optimize recentering on resizing for small views.
If that behavior is annoying, we can deal with it by being
smarter about when we trigger the recenter code.
(imported from commit 6834e11f7a37833982c388f15174df661d7f55b3)
We had this fascinating behavior where pressing a down arrow near the
end of the page would advance the pointer, call recenter_view, which
would trigger a scroll event, which would call keep_pointer_in_view,
which would notice that we were at the end of the page and advance the
pointer again!
I split out that last part into its own function which is only called
on mousewheel events.
(imported from commit bc85443e762356e3055f8f88585940a1f11f9124)
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)
Keegan McAllister
Waseem Daher
Tim Abbott
Jessica McKellar
Zev Benjamin
Luke Faraone