This is needed for the next commit so that the loading indicator is
created while its associated div is visible.
(imported from commit 72d6ccc14158b49e0ea640ab818114869aa548bf)
Prior to this commit, they weren't able to subscribe or unsubscribe
from streams or change stream colors.
(imported from commit 7f690c724bec3e7e6ba3b45ac7b41d1f7296b6f1)
If you create a spinner in a hidden element and then show the
element, the spinner is placed differently than if you had created
the spinner while the element was visible. This commit makes it so
that we never create spinners while their parent is hidden.
(imported from commit a21e68976d70fcceece30ee35f5e7cf6f9490497)
This allows us to use a uniform style across all our spinners. It
also cuts down on boilerplate HTML.
(imported from commit 9879f38e0f1ca8edd40a937753811e329447262d)
/?lurk=foo will show all messages to the stream "foo", regardless of
whether you're subscribed.
(imported from commit 049d98b3ee8df19ef0a9dc392ae941dd463f8dd5)
Before, a whitespace-only search would "highlight" the pointer and all kinds of
other interstitial space, which totally broke the page layout.
Fixes#408.
(imported from commit e7e0e251551a9da5a2ea53e36b9cce16e3e30634)
* Ignore beginning and ending whitespace when submitting the form
* Ignore beginning and ending whitespace when doing autocomplete
* Don't autocomplete on just whitespace
(imported from commit b3231e08f6797a38bafbcef2e694f4bae059c20f)
So that it is, in fact, navigable via keyboard shortcut. It's not the
most beautiful way to do this; in the ideal world the layout would be
more properly responsive and could fill up the screen for you when you
have the room for it.
The issue is that the version of Bootstrap we're running doesn't
easily allow for variable-sized modals, and the hassle of showing
and hiding a div manually didn't seem worth it.
The pixel sizes are specified manually as well, in a way that
isn't particularly responsive, because of a few competing
desires:
1) For them to appear side-by-side when wide enough
2) For them to stack when not wide enough
3) The fact that they're awkwardly between a span2 and a span3,
so we can't just use the Bootstrap responsive layout stuff
Finally, the diff here is best viewed with -w. (I also swapped the
order of Narrowing and Navigation, which unfortunately clutters the
diff.)
(imported from commit 62cfa7959d48ce515562713eb48f9d9b33c8cc16)
I'd like to phase this out in favor of something you actually
see only when you don't use Tab-Enter, but that's more challenging
than I'm prepared to tackle right this second.
(imported from commit eeda53b0ed69d0e528b00ea9e7c7a20edb35df34)
If you're currently composing a message and you click one of those, it
now no longer clears out your old message contents, making it more
analogous to the job the old selector used to play.
(imported from commit b935a3bf307bdbd82f1ee7db31d3a3c89c623195)
Accomplished by:
- Hiding the stream/PM selector
- Eliminating the "tab to send" reminder
- Moving send and formatting links to the right
- Reducing the size of the 'subject' box
- Generally tightening up whitespace
To be fixed later in this series:
- A Tab-Enter reminder
- Completely eliminating the stream/PM selector
(imported from commit 7efe04adcbe373f99a36d3ba23b32944c17aa099)
It can easily cost an entire line, and the information is available by
clicking on the sender's name. Plus on a phone, you can't hover
anyways.
Annoyingly, this tends to put the popover partly off the window, but
there must be a way to fix that separately.
(imported from commit 19334cb067981b323e300245654c83c8e545fb2e)
It's possible for selected_message_id to not exist in zhome. For
instance, when you open the page to a narrowed URL, there is a race
between loading the narrowed messages and loading all your
messages. If the narrowed message request completes first, it will
update selected_message_id to your initial_pointer if the latter
happens to be among the narrowed messages. Even if it is not, you can
select a message by clicking on it before the zhome request finishes.
Then the old code would never add that selected_message_id to the
zhome table, so it wouldn't show up in the Home view or if you
re-narrowed.
I'm pretty sure there are still cases where the selected_message_id
might be outside the range of messages in zhome, in which case adding
to zhome might put old messages at the bottom. I observed this twice
on staging but was unable to reproduce it consistently.
(imported from commit 162feff3090f8806cc67140db0cfabb6e965aece)