Since account deletion is async, the deleted account still shows up for
a split second. We can do something smarter about this later, but not
for ICS, and not worth it for such a rare event
Bug: 5116203
Change-Id: I82cced09b7a098e4a1a960f2d8ad75c1979b0649
This is a kludge - the real solution is to use the proper action modes
in the framework. That's too large to do this late.
Bug: 5232787
Change-Id: I76b68b250c384bdabf51e8831f833afd65c0c73b
- this syncs up the UX repo with the developer repo so that the assets
now match. We should be able to do wholesale drops/diffs from now on.
- lots of changes to widget so that it is (mostly) up to spec now, and
matches the preview
Bug: 5225385
Bug: 5205578
Bug: 4320895
Change-Id: I8ccbadcfc17cdb406599497edc91165809f55d68
* Rather than returning false, which can cause unexpected
results, e.g. locking out an account until reboot
* Partial fix for the referenced bug (there might be other
causes)
Bug: 5221119
Change-Id: I5b47093a3411deb6995624887197297323db0d2d
* A change in history requirement is not intended to force a new
password immediately; we just tell the DPM what the new
requirement is...
* This is one cause of the below-referenced bug
Bug: 5221119
Change-Id: I890b42d4eab4fbd9d34665fbea138f179d5d3215
* We were using the getSelectedItem() from the deletion spinner to
set the account's deletion policy, even if that spinner was
invisible (which it would be for IMAP).
* The result of this is indeterminate; sigh
* The fix is to make sure the spinner is visible before using its
value
Bug: 5216422
Change-Id: I7e44b5e8127f5277693f7e962899e8642be55239
- this is leftover from a time where we re-used a single WebView for
multiple messages. The current architecture does not rely on that, so
the clearView() is actually not useful. Worse - it's causing issues
because the operation in the WebView is asynchronous, so a clearView and
a load of the content in quick succession causes a race condition,
causing items not to load
Bug: 5205296
Change-Id: I5ee6697bdf53a033ba1c7f21170820259bf830d1
- minor changes to some icons (can't see a difference in some of the
cases?), larger changes to others (e.g. mark unread)
- xhdpi assets for a bunch that were missing
Change-Id: Id71d22aa50440cf6c83e4244bb807e3d237949c6
* We weren't checking for it in determining whether our policies
were active; because of this, we never actually SET the policy
in the DPM
Bug: 5193399
Change-Id: I276901be21be681f66891f5374ec58cf1ea7b4be
We had two separate "height" values in XML that weren't consistent - one
was used for the coordinates and one was used for the actual item i nthe
adapter. This made things off slightly when the values didn't match
(i.e. on tablet wide mode).
Also fixed an issue with paperclip icon not aligning with date on wide
mode
Bug: 5184169
Change-Id: I1d80bb9c685fdd8216fcaef26bf6ad715eb74c4c
* The existing IMAP search code is well-known to be primitive and
largely broken. In particular, it fails with any non-ASCII
character and with a variety of symbols (e.g. quotes, slashes,
etc.) Basically, it's an accident waiting to happen, returning
empty data sets even when the query might reasonably be expected
(or known) to return valid data.
* The current CL uses the IMAP literal string format to represent
the query text; this string can be sent either in ascii or in
UTF-8, and since it is sent as an octet (byte) count followed by
8-bit data, it also solves any quoting issues that might come
up. So, we kill two birds with one stone.
* The bug in question was punted to a subsequent MR; however, I
think it would be a mistake to ship the code without this
CL, which has been tested against the three common IMAP servers
that we aim to support.
Bug: 4690713
Change-Id: Iaa542bfc56737871f3cbc9c83f0e768415a7f2b6
Ben Komalo