Now that the InboxView is initialized in the background page context, we
can manipulate it more directly, without going through a global function
on the foreground window.
// FREEBIE
Don't wait for background init before rendering inbox.
If the client detects that it has become unlinked, it will not call
`init()`, never fire the deferredInit, and never render the inbox,
but we want to allow users access to their local messages even if they
have (perhaps temporarily) unlinked the desktop client.
Also, prefer not to extend Backbone.Model until/unless we really need
it.
// FREEBIE
This makes the "x" in the search bar always visible when there is
text in the search box, even if the mouse is not hovering, hopefully
making for a clearer UI around search and resolving issue #741
The implementation adds the "x.svg" as a background image to the search
box when it is classed with .active, in addition to the
-webkit-search-cancel-button, which is still there for the actual
functionality but only appears on mouse hover (one tiny snag is that
coloring appears slightly different on hover, at least on my screen -
don't know if this is a problem).
I accounted for both ltr and rtl text-direction by using
getComputedStyle(...).direction to detect from the input's dir="auto"
- if there's a more elegant way to do this, please suggest. An ideal
solution would use the :dir pseudo-class but it's not implemented
in Chrome yet - https://developer.mozilla.org/en-US/docs/Web/CSS/:dir
For now, I added the direction-checking to inbox_view.js. I see that
input.search is also used in new_group_update_view.js and
recipient_input_view.js but neither of these views seem to be in use (?)
and they don't set the .active class anyway, so I ignored them.
Update: Amended version a few hours later - fixed and manually tested
color and spacing for iOS and Android Dark themes. Also made some new
SASS variables to make things DRYer and fixed my tab size.
Handles the edge case where images in the Install steps can obscure the text below them at certain window dimensions.
In most cases, it's not possible to replicate this behavior due to minimum dimension settings in `chromium.js`. However, some window managers (such as i3) can ignore those settings, producing this bug.
This fix introduces a flexible, responsive layout to the Install steps, with the goal of keeping the action buttons in a consistent position while adapting the rest of the content to the remaining available space. The result is a clean, usable screen at any window size.
In the rare instance that a window's dimensions are less than that of the minimums set in `chromium.js`, scrollbars will appear to keep the smallest acceptable layout intact.
Potential side effects:
- Each `.step` element contains an`.inner` flexbox wrapper, which arranges its children in a column. The layout works best when each `flex-item` is an element that wraps the content inside of it. I think I accounted for all the possibilities on the Install screen, but any future `.step` items might want to keep that pattern in mind.
Resolves#1059
FREEBIE
Small change to clarify where the TextSecure server URL should be changed to the staging value in local builds.
It looks like the Android variable has been updated from `TEXTSECURE_URL` to `SIGNAL_URL` (ae40715526 (diff-c197962302397baf3a4cc36463dce5eaR179)) and the iOS counterpart is named `textSecureServerURL`.
FREEBIE
Adding the class `.text-security` to the body element will (should) turn
all names, phone numbers, and message bodies into unreadable squares.
Nice to have when you want to screenshot without leaking too much info.
Note that emojis and images are not obscured.
This isn't fully baked or exposed as a feature. You have manually
inspect and tweak the DOM to enable it, but I leave it here for the
benefit of devs and other "frequent flyers" of our issue tracker.
// FREEBIE
There may come a day when we may need to change this url from the server
side. On that day, clients should continue to operate normally. The
service should be able to change attachment server locations without
requiring a client update.
// FREEBIE
Expiring messages received before 0.31.0 may not have an expires_at time
populated. Loading these messages once will update their expires_at if
it wasn't already set. To avoid loading too many messages into memory,
add them individually, and remove them from the collection as soon as
they are added, allowing them to be garbage collected immediately.
// FREEBIE
Previously if there was no session to remove, the promise returned from
removeSession would never resolve, potentially blocking sending for that
recipient until restart.
// FREEBIE
