For now, just do this, and we'll reach out to realms having trouble
manually. We may eventually need to automatically reply to the e-mail,
reach out to a realm admin, etc.
(imported from commit 5c5ac354066f9e9be3fb928e1f8801613c22c1ac)
We do this because the upcoming Bitbucket webhook does not send
enough information for us to send a useful message for deleted
branches or force-pushes.
(imported from commit dcac675f47e10672125caabd6fefa8dc0dc9c86c)
Specifically:
* Fix the settings menu positioning and appearance
* Restyle menu and add arrow on top
* Remove labels from new message buttons in narrow windows and adjust the close button on the composition pane
(imported from commit 586753b6526289b32ec0a90b62d8b2ac1c8182cd)
This partially reverts d3c28b17859cacd49b7db9f8784d4b8b9069e1ff.
It is necessary to call update_floating_recipient_bar from _fade_messages and
_want_normal_display because they are called after opening/closing the compose
box. There is no scrolling there, so it is not otherwise updated. It is not
necessary to call from update_rendered_messages as it is not called on
changes of the fade state.
Related: Trac #1682
(imported from commit e2528f8c8827b7e2a135d7fc2b53e9e8162799b0)
I haven't filed an issue about this since I just quickly found and
tracked down the bug, but the STR were:
1. Subscribe to stream foo
2. Hide foo from your home view
3. Unsubscribe from stream foo
4. Unhide other subscribed streams you've hidden from home view, if any
The "All messages" link would stay, although it should go away in this
case. The apparent cause was an incorrect assumption (when implementing
this feature) that the stream_info dict only contains subscribed
streams; in fact, we also populate it with streams you used to subscribe
to.
(imported from commit 67f95c8c8a211a4943a2de394919d15a0d5435d0)
Specifically:
* Remove min width setting for the main div as it is no longer necessary.
* Change max width for the app to 1200 and adjust top margin on the message pane
(imported from commit 846dd3dcd7798efa615e15c61681b0ab7465f5e3)
This otherwise causes Unicode bugs. See for example:
>>> import urllib
>>> urllib.quote_plus("hello&world+whats@up?")
'hello%26world%2Bwhats%40up%3F'
>>> urllib.quote_plus(u"faraoné")
/usr/lib/python2.7/urllib.py:1268: UnicodeWarning: Unicode equal
comparison failed to convert both arguments to Unicode - interpreting
them as being unequal
return ''.join(map(quoter, s))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.7/urllib.py", line 1275, in quote_plus
return quote(s, safe)
File "/usr/lib/python2.7/urllib.py", line 1268, in quote
return ''.join(map(quoter, s))
KeyError: u'\xe9'
>>> urllib.quote_plus(u"faraoné".encode("utf-8"))
'faraon%C3%A9'
(imported from commit 7c13b749bdc7f89e7b767ddd630be0ebce30802c)
Once you enter a view, the last n messages will be exempt from
summarization, to give the users a little more context. Any
subsequently arriving messages will also be exempt.
We will try n=5 at first.
(imported from commit 3e6fe58109e692389bf02dde2230d788b5818d52)
For web pages, the initial favicon is the same as the favicon we
set for no unread messages and the initial page title is the same
as the page title we set for no unread messages. However, for the
OS X app, the dock icon does not get its badge updated on initial
page load. If the badge icon was wrong right before a reload and
we actually have no unread messages then we will never execute
bridge.updateCount() until the unread count changes. Therefore,
we now ensure that bridge.updateCount is always run at least once
to synchronize it with the page title.
(imported from commit 5d1269c62c1c3190aea96ef6f96c46acdb9fdf9c)
Dict.each() allows to iterate through values and keys of a Dict.
The callback function is passed value as the first parameter to
be similar to _.each()'s calling sequence.
(imported from commit e745e8b5d2f167b8b8acf7542b767494e354b037)
This fixes#1682, a recent regression that came out of
a5a47e13fc9d, which introduced the update_rendered_messages()
function in compose_fade.js. The original implementation
was finding the table row for a message, but not the table
row for its recipient bar. Now we style both elements.
(imported from commit a9628df0b03f79a24dfa68f4f2061eda2ca8ecea)
The calls to ui.update_floating_recipient_bar() were brought over
from compose.js, and it turns out they just complicate scrolling,
since we already call the function in the scroll handler.
(imported from commit d3c28b17859cacd49b7db9f8784d4b8b9069e1ff)