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)
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)
For whatever reason, specifying a percentage for bottom_whitespace
seems to cause issues in some browsers, including Firefox 17
and the Firefox Nightlies.
This is a bit confusing to me, since bottom_whitespace is basically
immediately resized by resizehandler initially anyway. But hey.
(imported from commit 93da101edeb6f16b01a92aed775e9117c0295086)
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)
Hopefully this will make things slightly more discoverable;
the previous solution (putting a prompt in the initial text)
was not that discoverable.
(imported from commit f6a7fce1bfd27bda412522768e981b2ffc39f474)
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)
Make it so the image is not squished, change some paragraphs into
headers, and wordsmith a bit.
(imported from commit 81295e1a8ddd4f1ecd4532c4dfb8a38467bb530e)
in the narrowed view, not messages older than the oldest message in
the home view
Tim provided most of the code for this patch
(imported from commit ec0bbfd344cac351f56a456fc560848603721135)
The tabindex on this link doesn't actually do anything, because of the Safari
tab workaround. I added it anyway in case we remove that workaround later.
(imported from commit 11f31f2561907300b350c11732be88589d736f94)
This fixes a bug where you could click on the already-selected mode button, and
it would switch modes without changing which button is selected.
(imported from commit 263ee0b52ba844c52a3a60968bb1bbff73482412)
With the removal of process_compose_hotkey, the state machine now has only one
state. Everything else is based on things like "is a text box focused right
now", which is probably a better approach.
(imported from commit 0e39c03956d28e30d2bdbf3b285410ad0cacca3e)
load_old_messages cares whether it is acting on behalf of a narrow
(for_narrow) not whether it is acting on behalf of a button push.
(imported from commit 16c00e015478f94f0631e211a92a7066a38135a8)
This restores the time-travel functionality and fixes Waseem's laundry
list of problems with its original UI.
(imported from commit e30e02c25af994435adb815d26284b3669c945a4)
This was causing glitching where if you narrow so that zfilt has only
one message, and add messages on top (e.g. via get_old_messages), and
then add messages on bottom (e.g. by receiving one), we end up with
the bookend row missing. One can make this happen with narrowing,
but, this situation happens every time with time travelling.
(imported from commit 71d85980d8aa9431a17b33e9e5111fd3f76cecf3)
If the message doesn't exist, rows.get returns an empty jQuery object, not
'undefined'.
(imported from commit 40620f3e4853a662cb93939bf7f0695f81298777)
This is so we only send a single pointer update when the user scrolls
through a bunch of messages at once.
(imported from commit 20d239d7179e5f57ada99968361a0f9b7b18c591)
Waseem Daher
Jeff Arnold
Reid Barton
Zev Benjamin
Keegan McAllister
Jessica McKellar
Tyler Hallada
Tim Abbott
Luke Faraone