de70ee5f7868ede7a738fbeb8ba9f9fe3558aefb |
25-Mar-2011 |
Todd Kennedy <toddke@google.com> |
Don't duplicate HTML in reply / forward On exchange servers that support "smart reply", the original message is actually appended by the server. In this situation, we should not append the original HTML text on the client. but 4177192 Change-Id: I6fad74ac761e2abfe7cb0f536df4db30f7d5ca9a
fc822OutputTests.java
|
8e09307b2743045239402645948155fd30cbb096 |
08-Mar-2011 |
Todd Kennedy <toddke@google.com> |
am 39121c75: Fix display of inline images * commit '39121c758dcc919b5fde4c893d488916e26d3140': Fix display of inline images
|
39121c758dcc919b5fde4c893d488916e26d3140 |
07-Mar-2011 |
Todd Kennedy <toddke@google.com> |
Fix display of inline images Inline images can be specified in two different ways -- explicitly with a Content-Disposition of "inline" or implicitly with no Content-Disposition. We correctly handled the former. For the later, we now default to an "inline" disposition if one was not specified. This is acceptable per RFC 822 which states: Content-Disposition is an optional header field. In its absence, the MUA may use whatever presentation method it deems suitable. Additionally, if the disposition is not specified by the server, we need to look at the Content-Type header for the file name. bug 2824698 Change-Id: I146f7a67197b4e737e5f82a3d570e0f74e23fa35
imeUtilityTest.java
|
d8bce7e73155dca734f45502e52c0039de4c9663 |
04-Mar-2011 |
Todd Kennedy <toddke@google.com> |
DO NOT MERGE Add original HTML message to forward/reply When replying or fowarding an HTML message, we now send both plain text and HTML bodies as a multi-part mime message. We take special care to ensure the message bodies are in their own multi-part block and do not interfere with any additional attachments to the message. bug 3060920 Backport-Of: I2fc3cb4e1f65bcc28486a62731b44b0ee0a99719 Change-Id: I89ec2795b55ceb7472a8ee3db2dc8f50cf537d9c
fc822OutputTests.java
|
9cc51b72c6902b95f65857af64eb38063aa4a42b |
01-Mar-2011 |
Todd Kennedy <toddke@google.com> |
Attach original HTML message on forward/reply When replying or fowarding an HTML message, we now send both plain text and HTML bodies as a multi-part mime message. We take special care to ensure the message bodies are in their own multi-part block and do not interfere with any additional attachments to the message. bug 3060920 Change-Id: I2fc3cb4e1f65bcc28486a62731b44b0ee0a99719
fc822OutputTests.java
|
0d49ef78ebc1b0d65c31241f5b38f95397eebe34 |
01-Mar-2011 |
Todd Kennedy <toddke@google.com> |
Change "appendQuotedText" to "useSmartReply" in Rfc822Output Slight API change to make it more clear what the method parameter is for. Also add some additonal test conditions to the Rfc822Output tests. Change-Id: I8888d6201e79136fa3420aa9d5f921772f374e56
fc822OutputTests.java
|
31d9acbf0623872f9d4a2b3210b5970854b654c7 |
12-Feb-2011 |
Marc Blank <mblank@google.com> |
Email split, part huit: Refactor constants, clean emailcommon * There are three pieces to this CL (sorry): 1) Move and/or rename some constants into emailcommon 2) Move Utility to emailcommon, moving the few UI related utilities back into Email (FolderProperties and UiUtilities) 3) Remove all references to resources from emailcommon * The three pieces relate in that, between them, they allow the emailcommon static library to compile cleanly Bug: 3442973 Change-Id: Ic5e3abaa2a1b36999e0b6653c6c2134ea1bd544f
imeMessageTest.java
fc822OutputTests.java
|
2193962ca2b3157e79f731736afa2a0c972e778a |
10-Feb-2011 |
Marc Blank <mblank@google.com> |
Email split, part quatre: Move along, nothing to see here * No code was harmed, er, changed in the making of this CL * All that's happened is that code that is needed by both Email and Exchange have been moved into emailcommon * This required import changes to many files, which explains the length of the CL Change-Id: I4e12455ba057a4a8054fdbd0b578c73afa411c8a
imeBodyPartTest.java
imeHeaderUnitTests.java
imeMessageTest.java
imeUtilityTest.java
|