1) Make the search hotkey (/) no longer clear the search box
2) Vertically center the "Search..." placeholder
(imported from commit 02dee6b72c4457e160f57d8604164e15e62f5f28)
This fixes Trac #723 - Message view scrolls to top after reloading on another tab (e.g. settings)
(imported from commit d9134cec6879625d577c43a08d258af3f6dacc5f)
Under some unknown circumstances (it happens on Keegan's laptop) the
loading indicator text width calculation returns a result that's a
few pixels too small. We hack around this by setting 'white-space'
property on the container div to 'nowrap'. The container's div will
be slightly too small (and thus the text will stick out the right
side by a few pixels), but that's probably OK.
This fixes#698
(imported from commit 2e5b28fb3a1fca78c700af74a452bfafd09a2da9)
This is to make the loading_indicator_text height closer to
loading_indicidator_spinner's height.
(imported from commit 062973e9c09b005601c5c943ce65dc97eeee179f)
This should fix the weird positioning spinners had when they were
created while hidden.
(imported from commit 777d5c376a3f93b0b7b3b749877070b438b7c102)
This changes the sorting for autocomplete to:
* Properly prioritize case sensitive and insensitive prefix
* For recipients, prefix-search on email, then sort by most recently sent pm
(imported from commit 893c7a07d678644a418a69656180fadf0d6f374d)
The fact that the user sees a change (the button changes or a row
appears) makes it obvious that the operation was a success. The
success messages were only serving to make the page scroll
confusingly when you couldn't see the top.
(imported from commit 471b9304f71bb8533c98d208b855d4d75c04a886)
The query fails anyway, so this is not a safety check. This commit
makes it so that MIT users actually see their subscriptions instead
of an error.
(imported from commit ee635943728d7d9823e118d9fa51c402b1cd9bf2)
We now keep around the subscription information for streams that the
user unsubscribed from in stream_info and have a field that
indicates whether the user is currently subscribed.
(imported from commit 973e2f4bd4139157b03d7c1a372db93a1a5130f7)
If get_updates requests a message ID that is too old, Tornado will
return a 400, and currently the only way to start caring about newer
message IDs is to reload.
(imported from commit 1638d71868475ffd793162afc7a2731cab14bd75)
Longer-term this should be done in a more sustainable manner, i.e.
including Glyphicons like we currently include Halflings.
(imported from commit 3f405c969352481626614a0d61874bd77f0388b7)
This commit both causes the settings button not to be drawn as
pressed, but also fixes the issue we were experiencing where,
e.g. changing from "Home" to "Settings" and back to "Home" would cause
you to lose your place.
(imported from commit 5084b280a202f6bf8f811834bf9d2734a034c8c1)
This is really the first step of implementing the "Oppa Gmail Style!"
redesign, and is largely an HTML/CSS-based change, with some
slight JS tweaks to deal with things being renamed or being no
longer necessary.
(imported from commit e05adc283ea066f0f90009cf712c4f3657c2485a)
Prior to this commit, at <979px, the .container in a .navbar has
`width: auto`, but a normal .container has width 724px, which causes
the two to drift out of sync.
This fixes that.
(Arguably, it's weird for us to waste ~200px scrunching
this down to 724px at this ratio, but we can solve that
as a separate issue later.)
(imported from commit 1f431ca1e2168db75821ea0be43941d29fd3e6b8)
We always want the navbar to stick at the top, no matter what
the screen size, and we want it to consistently look the same
height, etc. regardless of our page width.
This is possibly also accomplished via position: absolute !important
and other overrides in our own CSS, but this actually seems
slightly cleaner in a way.
(imported from commit 340fafb49bcbc1088a816897d320e252c4615d19)
Some time between the 2.0.4 and the 2.1.0 upgrade, Bootstrap broke in
a way such that clicking on a dropdown did not cause it to close.
Here's the bug thread about it:
https://github.com/twitter/bootstrap/issues/4497
I've implemented this workaround discussed there, though the bug is
fixed in 2.1.1, so when we upgrade this will go away (which is why I
only reluctantly tag it 'third', since the diff will not need to be
carried forward.)
(imported from commit f8d9cf65b33306a426d864c9b503bb3446614111)
When not in lurk mode, lurk_stream is undefined which caused
lurk_stream.toLowerCase() to fail.
(imported from commit 63ce79083b55a37cb0455871237a76d724fbbbea)
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)
We suspect that these seem to be causing a regression where scrolling
in narrowed views gets really sluggish, but we haven't totally been
able to figure out why since it's challenging to reproduce locally.
(It currently manifests itself on staging but not prod.)
So for now we'll back them out. Here's the full set of things:
Revert "Cause update_floating_recipient_bar to get called less frequently."
This reverts commit a6c1518c4001a2dde44d7b512236795da3ccd351.
Revert "Remove double-scroll in un-narrowing code."
This reverts commit 3dde6c27ffa1e8afa1a084b1b2baee3bc0512962.
Revert "Reset our scroll position if we change our hash to "#"."
This reverts commit 925b44d770c96dafaabebc9e0114f9a3b8f53c4d.
Revert "Properly update floating subject bar when you are at top of page."
This reverts commit 6633cc8a81aedcbb31b30d7c1f27816f8808c700.
(imported from commit a273730581cef30c33bedf701659ee084434f8ad)
Putting update_floating_recipient_bar in the old location caused it to
be called on every single keypress, which is unnecessarily
expensive. Instead, just call it once when we think we might actually
need it: after initiating a narrow.
(imported from commit a6c1518c4001a2dde44d7b512236795da3ccd351)
Watching new users, I've seen them not notice the pointer and
mix. Give them a little more hinting about what message is selected.
(imported from commit c98e22dcef881ed7400071ec438a6e91d6cd3d9e)
select_message_by_id with then_scroll: true already recenter_views
on the selected message; no need to also call scroll_to_selected.
(imported from commit 3dde6c27ffa1e8afa1a084b1b2baee3bc0512962)
Changing the hash to "#" causes Chrome to jump to the top of the page
on Mac OS X. This commit doesn't actually fix any bug, but it
is necessary for my *next* commit, where otherwise you'd have to
ensure that the scroll code came *after* the hashchange code.
(imported from commit 925b44d770c96dafaabebc9e0114f9a3b8f53c4d)
There's this very edge-case issue which is: if you go to the top of
the page and narrow to something other than the top message, the
floating subject bar does not update.
Why? Well, the way that the narrowing code works is that it sets up
narrowing and then calls
select_message_by_id(target_id, {then_scroll: true});
so that our selected message is in the view.
This in turn calls select_message, which calls recenter_view as
appropriate. This usually causes a scroll action, which in turn causes
the floating recipient bar to be updated.
But when we're at the top of the page, recenter_view doesn't need
to scroll at all! So the bar remains un-updated. Here we explicitly
update it to guard against that case.
This fixes Trac #651.
(imported from commit 6633cc8a81aedcbb31b30d7c1f27816f8808c700)
I don't view this as a complete solution to
Trac #466 - Make the fact that you are narrowed more apparent,
but it's a start.
(I think a real solution would have to give you something that
helps you make the determination of "Is this view narrowed?"
when you come back to your computer, and this animation does not
help you do that.)
(imported from commit eb3646f3f3a4e25a43266e9146308633fd997eb2)
This commit just moves around some lines so that the code that
hides the main view and shows the filtered view, or vice versa,
are together so that it's easier to reason about the sequence
of things that's happening.
(imported from commit 7e99f45293c0e1a4cdfa1a08f41f8c770c370d6c)
This used to be a button that let us un-narrow, I guess.
A git grep for it after this commit turns up no actual
references to it.
(imported from commit 05acb4bb40da1b032f548c511fbae5b2b20874a8)
And change the color to a more thematically appropriate blue.
The shadow pointer is sort of confusing; we should really provide some
different sort of indication that your pointer is potentially moving
on narrow-and-unnarrow. (I think my fade-in-fade-out later in this
commit series is a not-bad first crack at this.)
Resolves Trac #472 - Dual pointers in narrowed view can be confusing
(imported from commit 2450517d99de85ade1c0e98c5510b59e70282451)
If you narrow to a view that only has one or two message, sometimes
the grey box gets cut off and doesn't go to the bottom of the
page. This fixes that.
(imported from commit 55724d03aa30922d91bd33fab4447d889be78889)
The initial rationale for hiding the floating recipient bar
was that it duplicated information that was in the "narrowbar".
Now that this no longer exists, let's *always* show the
floating recipient bar.
(Yes, there is some duplication of this information in the
search area, but I think the situation is fundamentally
different now and would basically like to see it everywhere.)
(imported from commit 6fd4506c2f48caade9496139e580e6550252ce8c)
Alternatively the server could return a successful result with an empty list of
messages. But I prefer the solution in this commit, because it would allow us
in the future to warn the user about the problem. It does allow users to
determine if a given stream exists, but we haven't tried to hide that
information so far.
(imported from commit a91e12c90b12d3c870c0b637c3f1d6d3cef88491)
It's cleaner if the filtering code recognizes only one value.
We can add this back in by converting in the parser.
(imported from commit 453b7b01e094955c6d66be63b5d997cc56b50a35)
Show the buttons iff
- the search input is focused,
- the search input has non-empty contents, or
- we are narrowed.
(imported from commit f5c98471a2db4ab522160960dd1271471a9db555)
We don't require that the parsed form be lower case; that's handled by
narrow.activate. However we unparse as lower case, in order to give the user a
hint that matching is not case sensitive.
(imported from commit 2882b440deb59a049b095db7a13cfc18e047caec)