/?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)
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)
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)
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)
