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)
Importing zephyr.views here has the unfortunate side effect of
creating Client ids 1 and 2 automatically (via decorators.py
instantiating the two client objects it makes), before we go ahead and
delete all objects in the database as part of the populate_db startup.
(imported from commit da03cb7606334d5926e42f422ab94d1c884937b9)
This was not totally effective, and with the previous commit it is no longer
needed.
This reverts commit e86c0b653669cf86b0d8956c2c85eb7610fc342f.
(imported from commit 0de5bfec87147b1336f6f79c33d4e32493e1e508)
Previously, the StreamColor restore code didn't properly account for
the fact that most user subscriptions were in pending_subs and thus
not yet in the database.
(imported from commit 2e28c5a68aa045494b9336d7114c23f5c3706c28)
By processing UserMessage objects in batches as we go, this avoids
consuming a large amount of memory that is linear in the size of the
messages log.
(imported from commit 0c42d97f0863da9c079836c60bebcbaeec59f849)
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 is useful when testing the sigup workflow, as this script enables you
to run through a MIT signup without manually creating a new inactive user
in the database.
(imported from commit c22649cc7c561c2fbe8682d1b17d7e5aba9ac04e)
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)
We previously were only using it at the first loop through all
messages, which meant code accessing the message type copied from one
place to another would break (potentially subtly), because things
would work if and only if the very last message happened to have the
same type as what is expected in the relevant piece of code.
(imported from commit ad9ce5efdb200e0c0d5c3ffa6db33113fdad8c5a)
This addresses Greg Price's feedback in #527. We now distinguish
between normal pushes, force pushes, and branch deletions.
(imported from commit 0fab6055f63ffc7e6df283b8bb8ed9971000e6d5)
This cuts a 30s operation down to about 2s on my machine.
And also move the code to run before we print the "done" message and
have logging for how long it is taking.
(imported from commit 2f20f8ca3fee714735a50fe6c6cfd630df452768)
This is syntax like
Here's [a link][]
[a link]: http://google.com
This is not very useful for short chat-style messages. It will confuse users,
especially because we don't document it. And disabling it saves the effort of
applying the same link fixups as elsewhere.
(imported from commit c23391465486db545302b79c084b4f9cd5cdcc6a)
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)
This is an interim strategy for user education that'll be a stopgap
until we build something in the app itself.
(imported from commit 9022d4ceffca98e127f7045f73c012857fe6fc54)
When we changed our stream name model to treat stream names as
case-insensitive, we didn't update populate_db to do the same.
This commit makes that update, which is to use the lower-cased stream
name for dictionary lookups and deduplication, but the original-case
stream name for actually creating streams.
(imported from commit fc32ec75a5ae286bce7ec86c6e6fb6893888cbd0)
bulk_create_streams was taking about 10 seconds to run with prod data;
this should be a basically immediate operation. The cause was a
missing select_related on one of the loops through all streams.
(imported from commit 8b82f0c41facc3999bb699dbc350708ac69797e9)
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 transaction.commit() line inside the except IntegrityError clause
doesn't work unless we've entered transaction management.
(imported from commit 2ae520e05c9a19ec35af7c244631b01d4b9598d6)
This makes subscribing to zephyr classes for the zephyr class
mirroring bot a lot faster, since we don't need to subscribe to the
third of our streams on which no users will actually receive messages.
(imported from commit 029b7fb260b480db5599e3c9f9effc502f6d8b59)
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)
During long-polling mode, we were not passing the server generation
number back to the client even when they requested it. This was
causing the web client to initiate reloads every time it got a
non-immediate return from a long-polling request.
(imported from commit 66c16bf5a1c18bdd975b09d672ebdb4db8d4755d)
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)
authenticated_api_view and authenticated_json_view call
update_user_activity with a client generated using
@has_request_variables with a default of e.g. get_client("website").
Because that get_client call only happens once on importing the
module, if those client objects didn't exist previously in the
fixtures, then the first test will generate objects with ids 2 and 3,
and then the second test will dump the database, restore from the
fixtures, and then eventually generate client objects with ids 4 and
5. But since the default values were only computed at module load,
we'll still end calling add_user_activity with client objects with ids
2 and 3, which don't exist in the newly restored database.
Fix this madness by just making sure those two client objects exist in
the database.
(imported from commit d940e129d077a560d9a0f96ec3daa2e16ce21c8b)
If the message doesn't exist, rows.get returns an empty jQuery object, not
'undefined'.
(imported from commit 40620f3e4853a662cb93939bf7f0695f81298777)
Previously, if the client was not interested in pointer updates, they
would still return early from get_updates() when the pointer was
updated.
(imported from commit ef9d8b5678b7e72f799840148577651ee10d47ad)
Realistically, if there is a pointer update, no other client is going
to have the same pointer. If they do, the client can ignore the
update.
(imported from commit ca2db60ed7a7c5e4b50a9fa8d350985460922a50)
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)
The assertion-checking callbacks were never called before. Now they will at
least get called when the view invokes handler.finish() before returning, i.e.
the return_messages_immediately case.
I fixed up the assertion-checking callback for one of the test cases. For the
other two it wasn't clear what to do -- one has been known-broken for a long
time -- so I just removed them.
"Fixes" #277 in as much as that test case is gone now.
(imported from commit 82d1db26f36f82f24aa5b7ff9e5aa65ce24c9a8f)
Run this script on an existing realm to create or change default
streams, which new users will get upon account creation.
(imported from commit 8938dcbd3520d97d25b4c6ca783d35c9aef52df0)
Ensure that every result has one of:
* find what you typed in
* search for what you typed in
* Narrow to a stream related to what you typed
* Narrow to a person related to what you type
(imported from commit 2178f17932f951a48f53d982ef660942562b55dc)
Modify the Bootstrap default sorter to sort by:
1. Starts-with, in a case-sensitive way
2. Starts-with, in a case-insensitive way
3. Matches anywhere, case-sensitive
4. Matches anywhere, case-insensitive
(This fixes the Keegan-reported issue of "Testing!" taking precedence
over "test" when he types in "tes")
(imported from commit b2a0127956fe7a8bf1cbf30752a6ddc2c49b7198)
(But don't actually make it work yet -- that's for the next commit.
This makes the diff a bit easier to review, since it's really just
code moving from composebox_typeahead to typeahead_helper, and the
appropriate changes in zephyr.js, rather than code moving AND
changing)
(imported from commit 5cb2e836eeb8807f4eb98424558702d44a0e2b70)
We'll probably eventually get fancier with this, suggesting various
default sets depending on the company or making it easy for one person
to create default subs for several people at once.
Until we know what we want, keep it simple.
(imported from commit 14319dd50c67fe33ac6f15288dba4916ce0a89ac)
If Javascript breaks or stops working, the previous hack means that
Tab-Enter stops working on Firefox and Chrome (since the tab key now
needs to select two divs before it gets to the Send button.)
By putting the one div *after* the Send button, we ensure that this
keeps working gracefully on Firefox and Chrome (and presumably IE), at
the expense of Safari in this specific case.
(imported from commit 9c9a613b1b1718ff8f0b9ef7497ebb13db0ddc64)
The main problem with this code is that the error message doesn't go
away until you reload. To fix this, we need to add a noblock option
on get_updates.
(imported from commit dc45af397bcf06a218bda5dd224ebd5fdf3462db)
The reproducer for the issue here is:
- Scroll to the top of your feed
- Click on a stream name
- Open a popover
- Click on a subject name
- Note that your old popover doesn't go away, and that you can open
a new one.
The problem was that when we narrow, we call jQuery.empty() on the
zfilt table. That not only removes nodes but also clears event
handlers and jquery data. Thus, even though we have a reference to
the old popover element in the ui module, the element has forgotten
it had a popover. When we call .popover("destroy") it actually
creates a new popover, but never shows it.
(imported from commit 9721d60c78549bd2362833590b304952f2bdef2d)
When we switched to delegated event handling, the bound handler for
all of our events was #main_div, but the floating recipient bar lives
outside of #main_div. Additionally, the bar needs to inherit the zid
from the target recipient bar since it is used for the narrow.
(imported from commit 7c18e16f2e98436888a8edb81fbbdd4d17abfe2a)
The problem seems to be caused by a bug in Firefox. We work around
the issue by adding empty table rows to the top of the table and
removing them when the user is idle.
This resolves trac #413
(imported from commit 2b15a4a2241bd7e813800a42608d650e0d4fa4f0)
I'd like to think about how to polish aspects of this a bit more,
but would like us to be able to deploy master at some point today.
This is basically the philosophical equivalent of reverting the
user-visible UI changes introduced in
b7b6794ad635ec63269a2043cd48b02749fbffda
(imported from commit edfaadf26741c47120c3acf6c410d33025c0a260)
Previously, it was impossible to narrow to a completely empty narrow.
Now it is possible, and the code needs to be tweaked in a few ways
not to break in this case.
(imported from commit e4dd4159ad52d003fc11d0b8b6531322c12a3de8)
Fixes#396.
We could display an error message, but jumping right to the login page seems
smoother and conveys the same information.
This will discard any message being composed, but preserving it would have
security consequences that we should consider further before implementing that.
Hopefully, users only get logged out by an explicit action, so they can't
complain too much (but see #217).
(imported from commit aaa23ecf46c73e514117ae1010fc44e133f2ba07)
Previously, we were adding those narrowed messages to message_dict the
first time, and thus totally skipping those messages each additional
time you tried to "load old messages" on that narrow.
(imported from commit 77eef376e1165b86e3c599608a1b5089a09d51e0)