There are other focus issues related to switching between a class
message and huddle during composition, but this fixes the immediate
problem.
(imported from commit ec7ebc1c68e52942e9eaa0ea61e0de2f6ccae521)
This also helps us manage checking, case-insensitive, for
subscriptions while preserving the casing used by the class creator
for display.
It also fixes a bug where the class_list would become out of sync with
your true subscriptions, allowing you to appear to send messages to
classes to which you had unsubscribed.
(imported from commit 5e8d017bcfb27a71c52f7517733eda7b926d721b)
That way you can at least see them by hovering on them if they're
too long. (I'd probably like a better solution long-term,
but this'll do for now.)
(imported from commit 8628be101475ea72865bcaeda7d7f5cfe6453931)
So what's now happening here is that the outer div (which we were
previously animating) doesn't get animated at all; instead it is
simply made visible or hidden.
I *believe* this means that it always continues to take the same
amount of space in the DOM; its being added and removed seemed to
cause a slight height-of-page change which caused the scrollHandler to
fire, causing the selected message indicator to move down the page.
So now that this height is fixed, we achieve the animation instead by
animating the inner div -- the one that actually contains the
composebox elements.
(imported from commit 95b2f95d52254e3792633460f42efaac27559efe)
The issue with the animation is that it removes the composebox div
when it's done -- or more relevantly, it "adds" it when the composebox
appears, which causes some DOM elements to get reshuffled slightly
which causes some jitter.
(Similar to what was happening with the email addresses earlier.)
So instead of using display:none, we play with visibility:hidden,
which causes the thing not to show up, but doesn't cause it to
lose its place in the DOM.
(imported from commit a18dbdcd1784b2b54436d48d8425d5fdc8dfbba4)
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)
This is a regression introduced by switching from links to buttons,
which get blurred by hide_compose.
(imported from commit f5aa67cb949f3edc7f86a0ef0d7f48b43860138b)
This also prevents the "bounciness" associated with the fact
that the stream/huddle selector was an absolutely positioned
div relative to the bottom of the compose window.
(imported from commit 413003a83c187efd45d0281f7cb6c9d0bd550674)
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)
Potential downside: If you were narrowed and went to, e.g.,
settings, you would lose your place. If we wanted to be more
fancy we could have this code fire only if you were already
on the #home tab.
(imported from commit 5e8d90ba255076a11aa6f7a58c447156729ca23f)
href="#" will cause the browser to jump to the top of the page, which
breaks everything in the scrolltheworld world, unless you suppress the
event.
(imported from commit ae03cbb9e8a82f28e8536f29485e9e947e7e76c2)
The form decides which fields to require based on whether
or not the personal-message bar is showing. Hide it by
default.
(Otherwise, both the 'Stream' and 'Huddle' prompts show up,
and you're obligated to fill out both of them.)
(imported from commit 13521ed5b7849f41c0335157d468f5e463c7f62d)
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)