When determining if desktop notifications are enabled, we can check whether
there is a "window.bridge" element.
Now when it comes time to actually send out notifications, we can just test
again for the existence of "window.bridge" and if so, shunt the data over
it.
(imported from commit 8104c91ea9da7bc485c86a3c21edc88905d2f47b)
Before this fix, the code would restrict the pointer to be above
either the 1/2 mark or 2/3 mark of the page, depending on your
scrolling direction. This fix makes it so that the system leaves
your scroll and pointer alone when between the 1/5 mark and 4/5
mark. This means the user can read more messages on the screen
at a time before getting paginated.
(imported from commit 98f6319bf63181dd331e037ac20a0c15518725ea)
When you make a call to set_message_position(), you already
know that the pointer is gonna be onscreen, so set the flag
to suppress scroll pointer updates. This should be faster and
also avoid future confusing bugs where recenter_view() and
keep_pointer_in_view() run for the same event.
(Both callers to recenter_view pass in the selected message,
and then the calls to set_message_position() set the scrollTop
so that the selected message shows onscreen.)
(imported from commit f1a6f189b7899b280a6316ea7eb03f015d3d4ae3)
This also changes the color for the blink effect when you
get private messages. For simplicity sake, we use the
same color for private messages and mentions.
(imported from commit 46b0f7af1dccefe575004e7676990e5c854a3dcc)
Previously it could return an array or boolean, and this inconsistent
interface had several latent bugs where consumers of the API only
considered it returning one or the other type.
This also fixes a specific bug a user triggered by being narrowed to
nothing (/#narrow) and clicking in the compose box.
(imported from commit 64ca2a37a9f288066f89b0ddec6638e010704eb0)
Re-focuses on the compose box after a send, under these conditions:
1) narrowed to stream+subject -or- responding to PM/huddle
2) compose was initiated by clicking on a message or hitting "r"/"enter"
3) cursor has not moved since you've started the composition
Additionally, if you are thus narrowed, we will move your cursor when you've sent
a message to that message, assuming that such a message initially appears visible.
(imported from commit 373c858081694e6fc9994639340a847d66edb566)
This change fixes the barnowl scrolling so that the ratios of
1/5, 1/2, and 2/3 are all relative to the visible viewport.
The core part of the fix is that we need to call
ui.message_viewport_info() to get the correct offsets for
the top/height of the actually visible viewport Because
this function is fairly expensive, I didn't want the
helper functions needlessly re-calling it. I could
have passed the helper functions the structure, but at
that point it was simpler to inline their functionality.
(imported from commit fb10d99313d568e85acfa70703c4651466acbc21)
Now that this functionality is accessible from the right sidebar, we
don't really need it here.
(imported from commit 34eaef4e1200f9fc673a681f0be87d8008033e83)
Currently, this is accessed by clicking anywhere in the sidebar region
other than the text of the person's name itself, which does the
existing narrow behaviour. Later we can make it do something clever
with hovering pulling out the popover or something, but that's
potentially a significant design project I think this is good enough
to be useful.
(imported from commit a2cc5dc851661117a6d438ca48a1ce7585d4eb63)
Previously if you had been invited twice to use the app this management
command would fail with your address, since the email address was no longer
unique.
Now by unconditionally generating a new PreregistrationUser object we avoid
this problem.
To test, invite a user to Humbug via the webapp twice, then generate an
invite link for them manually. The latter operation used to produce a
traceback, but now works.
(imported from commit b6c816187e6302b3cb3eea2928565b3a12046c4b)
We had a couple places where autoscroll would
mysteriously midway through scrolling, and it
was because scrolling generates mousemove
events.
(imported from commit 666e5e5af81fdcc5cc56c314d1264dbec970c067)
Treat "mentioned" messages like "starred" messages for narrowing.
Lots of ugly copy/paste here. There might be opportunity for
some cleanup in places.
(imported from commit e7629890d42643c0000e1cc85422b2a0690f2cc4)
We now don't use these at all, and they are likely to confuse us later e.g.
when modifying third-party files.
(imported from commit 2034949111466b22b1830ec087f30fa34445fcbd)
We will provide our own copyright and license comments in the files
that need them
Also remove the byte-order mark from spectrum.css. It would appear in the
middle of the file, and there's no need in UTF-8 anyway.
(imported from commit dc32113e88bc6533f37f3378ffeac26f2050d0e7)
The bug we experienced here was that if you loaded the page in a
narrowed view, and then un-narrowed before the first block of messages
for the home view arrived via load_old_messages, then
narrow.deactivate() would re-select ID -1 in home_msg_list. This ends
up calling recenter_view() on the message, which in turn tries to
access the message with message id -1, which fails.
We do sometimes re-select a message ID in order to recenter the view
properly when we prepend messages to a message list, so we can't make
this always a nop; instead we add a check for id -1 in the
message_selected.zephyr event handler.
(imported from commit 66f84a586e59d99aaf0e4ba2cda9fe597b033145)
Luke Faraone
Steve Howell
Jessica McKellar
Leo Franchi
acrefoot
Tim Abbott
Keegan McAllister
Zev Benjamin