The message timestamp is now always clickable, and the popover contains the
full long-form date and time. This addresses one problem from usability
testing (see #470).
(imported from commit ad502dff128ad1c934fc0d3faaf5e2931c91c37e)
Bootstrap ignored this and instead used the title= attribute, containing the
full timestamp, which seems like what we want.
(imported from commit 8442835d61f89bd0bce75c05e17aabe85e0f417c)
The interface is a little messy because so many of the inputs change
-- we need to better organize all these variables under centralized
'zfilt' and 'zhome' headings.
(imported from commit b247e86bf63ea2ea2c0d42ef23e8af0ce288d5dd)
So here's the reproduction recipe:
(1) Find a narrow that doesn't have any messages since 4 days ago
(2) Directly visit that narrow in your browser (or wait for someone to
do a deploy and thus auto-reload)
(3) Wait until load_old_messages has been called at least once
(4) Un-narrow
(5) Scroll up, and notice that the 400 most recent messages are above
sets of older messages.
The cause is that the code in add_messages assumed that
selected_message_id was within the range of message already in the
home view. This is true in most cases where add_message is being
called, but it is not true in the case that the user was in a narrowed
view containing only very old messages (And thus selected_message_id
would be older than everything in the home view).
We can fix this by tracking persistent_message_id separately and using
that for the relevant test in add_messages.
(imported from commit f0da2561ba68f729343b260adc398029fae6acf7)
Prior to this commit, successfully creating a stream (or unsubscribing
from a stream) didn't clear earlier error messages.
Here's how you could reproduce it:
* Try to subscribe to ""
(You get an error)
* Now unsubscribe from something, or subscribe
to a new stream
(The error message does not go away)
(imported from commit c3c6fa6081df00378182ff0c3499e9d907577c04)
Prior to this commit, we also cleared out all of your checkboxes,
which is frustrating if you wanted to invite another person to the
exact same set of streams.
(imported from commit 389f27ec35dc9bf8c9058c5ffa867929ac90f674)
Because a stream can never stop being invite-only, we don't
actually need any Javascript to manipulate this besides what's
in the Handlebars template.
(imported from commit 30dc3b0baf623d88d03a643f18cd411dbe3eacfb)
This allows us to remove fetch_colors() entirely, and should speed up page
load a bit.
We also JSONEncoderForHTML instead of dumps so that the result is safe
to embed.
(imported from commit 013630911960e2ac1d0bae6f5df31ad342750594)
This will give us flexibility in the future to add new properties to the
list.
In order to support that, we now do a list comprehension rather than just
returning the gather_subscriptions list in get_stream_colors.
(imported from commit a3c0f749a3320f647440f800105942434da08111)
In preparation for re-using the /json/subscriptions/exists request on
the subscriptions page.
(imported from commit 76eca95b952c4b60e583a050be711023ee5fedac)
Prior to this commit, if you have the composebox open, pressing 'c' or
'C' clears its contents. This change makes it work more analogously to
pressing the 'New stream message'/'New private message' buttons.
(imported from commit 3de5bf83754d8ab86b1967ce2ba15f5846090667)
As it currently stands, after the introduction of operators, narrowing
to messages that contained X would also trigger a find-in-page.
This stops that from happening, and then also makes the default action
of the search-bar-invoked-without-a-typeahead be 'narrow to messages
containing x' rather than 'find in page'.
(imported from commit 1beffce426c6b00449e7c1c803687a129747ed63)
This is a tricky one because it's kind of hard to see locally, but
there's a bit of a delay between when you click "Invite" and when we
get back to you. So we give the button a "loading" state so you know
not to click again.
(imported from commit 9c3389a3d06def777427c846d6106f6d9b30cc8b)
Leo points out that if you type a stream name, we probably want
to offer to narrow you to that stream more than we should offer
to find that stream name in the page.
(imported from commit 803ac681ec2f759f4dabb68a40722a07b86a0cab)
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 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)
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)
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)
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)
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)
Also removed .show()s for the alert on does-not-exist and not-subscribed, where
a blank error would display. This should fix the underlying issue with #166:
that hiding the composebox before send_message() was called would hide server
errors.
(imported from commit a8a50cdf82ddf1d15f1e405432ff3bbfdb7a491a)
If you have a lot of subscriptions that you're trying to modify,
jumping back up to the top of the page is very disruptive. We still
show the success message, which has the effect of scrolling the page
and is thus surprising, but that's better than the user completely
losing their place.
We do need a story for informing users about failures to subscribe or
unsubscribe, though. We currently jump back to the top so they can
see the error, but that's not optimal.
(imported from commit 48d938ddc47f286a72e2147f4459b91ca5684e36)
CSS height percentage was not working because parent div has an undefined
height, so instead it is set to 40% of the window height on resize (and initial
load) via JavaScript.
Fixes trac ticket #24.
(imported from commit 2c6a8489585c4bf70c44469ce8628264ec3fbc36)
Variables like stream, subject, and message were getting cleared from the DOM
when the compose box was closed. The "Create and send" button was trying to
access these variables to create a new stream, but they were gone. Now they
are cleared when a new compose is started.
Fixes trac ticket #568.
(imported from commit 39ccaaeacb3f92f4b1d771be1b34ff660e0d5883)
We were submitting a 'last' value of -1 to the server at startup,
which is invalid but normally ended up being OK because the user
usually had no messages whatsoever or had last be updated via
get_old_messages before the get_updates call went through.
(imported from commit df55ac1cdac443721c06ebed94a1c4b3ec7af2d1)
This was not totally effective, and with the previous commit it is no longer
needed.
This reverts commit e86c0b653669cf86b0d8956c2c85eb7610fc342f.
(imported from commit 0de5bfec87147b1336f6f79c33d4e32493e1e508)
This was causing issues with our ability to unsubscribe from
streams with " in their names.
The solution here is a bit hacky, since it depends on the JavaScript
being fairly aware of the layout of the DOM, which is not great.
But it works.
This fixes Trac #328.
(imported from commit a1b6c8e1f3a9daacdc48920a195717aa89b3a9a9)
This fixes Trac #522, which previously prevented you from
subscribing to a stream named
'"]'); alert('hi');
This does not fix#328, which is that you can't unsubscribe
from 'Waseem', among other things.
(imported from commit 869063cafa9e7e988aea993d072ca1ad880bcee1)
Unfortunately, this doesn't actually give us much performance gain
either; it's not really the calls to 'find' that are taking any time.
But I do find this a little cleaner as well.
Simply initializing 100 colorpickers with our options takes about 700ms.
Initializing ~100 colorpickers with the total default set of options
shaves that down to about 300-400ms (though obviously doesn't quite
achieve what we want).
(imported from commit 7084b35fb6e77600edfcdcfcc2761a11e6f38c03)
Rather than calling the template generating code once per
subscription, let's just do it in a batch when possible.
With about 100 subscriptions, the "fetch" call takes about 800ms to
render (while testing locally) both before and after this change,
which is somewhat disappointing.
But this *is* cleaner!
(imported from commit 9ba8819524da86c00a2508349be0ea0ddd48606b)
This fixes https://trac.humbughq.com/ticket/546.
It's a little unpleasant that this special-casing lives in hotkey.js
-- instead you could imagine doing something where there was a whole
special set of hotkeys when a search is active, like we do with the
composebox, but this gets the job and is probably simplest.
I would have written this as a case that just falls through in the
else condition, but jslint doesn't like that.
(imported from commit 65a1b8aa1efc356b6690dc177058a4fb9e12745a)
This was a really cute bug where our layout messes up if you resize
the page while "Subscriptions" (or to a less visible extent,
"Settings") is active.
The problem here is that we compute the size of the top navbar
based on the size of main_div -- but when main_div is hidden,
it has a width of zero!
We need to instead look at the width of the pane that *is* active.
Resolves https://trac.humbughq.com/ticket/216
(imported from commit adbef00d190845f90c5cfdb46df4ec7b703635ef)
feedback-bot and zephyr_mirror will need to be updated and restarted
when this is deployed to prod.
(imported from commit fe2b524424c174bcb1b717a851a5d3815fda3f69)
Ironically, I think this might've bee introduced by
commit ca35321c02d5e79e4f9c439a662805c016a333ed,
'Fix "resizing window breaks in Firefox" issue'.
Basically, when the window is 776px wide according to
window.innerWidth, that's the width not including the
scrollbar. However, in Chrome, the media query seems to ignore the
width of the scrollbar, so from the CSS's perspective, the window is
actually ~766px wide, so it goes into condensed mode.
But the rest of our code doesn't, which causes the break.
A bit more on this browser-specific difference at:
http://www.456bereastreet.com/archive/201101/media_queries_viewport_width_scrollbars_and_webkit_browsers/
So the issue we have is, to match the CSS's behavior:
* In Firefox, we should be listening to window.innerWidth
* In Chrome, we should be listening to window.width
We fix this hopefully once and for all by using window.matchMedia --
aka the exact same query that the CSS itself uses. As discussed in my
last commit, this feature is unavailable in IE<10, so we provide a
potentially more fragile fallback, i.e. what we did before this
commit.
(imported from commit d8e6425b81c90c8e0fdda28e7273988c9bfd67ec)
Keegan McAllister
Jessica McKellar
Tim Abbott
Luke Faraone
Waseem Daher
Jacob Hurwitz
Zev Benjamin
Leo Franchi
Jeff Arnold
Reid Barton
Tyler Hallada