Assigned
Status Update
Comments
ch...@mixmax.com <ch...@mixmax.com> #3
Project: platform/frameworks/support
Branch: androidx-main
Author: Louis Pullen-Freilich <
Link:
Revert^2 "Fixes issue with dragAndDropSource preventing child invalidations"
Expand for full commit details
Revert^2 "Fixes issue with dragAndDropSource preventing child invalidations"
This reverts commit 3d5fd7d04bdd7f02ee2b215af68b2832e06134bf.
Reason for revert: Underlying bug b/389046242 is now resolved
Fixes: b/379682458
Test: DragAndDropSourceTest
Test: AndroidDragAndDropIntegrationTest
Change-Id: I07cb2a4091b46d862628bf17625ae9d9eb087641
Files:
- A
compose/foundation/foundation/src/androidInstrumentedTest/kotlin/androidx/compose/foundation/draganddrop/DragAndDropSourceTest.kt
- M
compose/foundation/foundation/src/androidMain/kotlin/androidx/compose/foundation/draganddrop/AndroidDragAndDropSource.android.kt
Hash: 3c48a0fbd3c2902a6a7acb6c8b474a4928b1be41
Date: Mon Jan 13 09:46:38 2025
tr...@gmail.com <tr...@gmail.com> #4
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.foundation:foundation:1.8.0-beta01
androidx.compose.foundation:foundation-android:1.8.0-beta01
androidx.compose.foundation:foundation-jvmstubs:1.8.0-beta01
androidx.compose.foundation:foundation-linuxx64stubs:1.8.0-beta01
androidx.compose.ui:ui-android:1.8.0-beta01
androidx.compose.ui:ui-jvmstubs:1.8.0-beta01
androidx.compose.ui:ui-linuxx64stubs:1.8.0-beta01
ry...@google.com <ry...@google.com>
ki...@iriscrm.com <ki...@iriscrm.com> #5
Having the same issue, do you have any update on that?
ek...@google.com <ek...@google.com> #6
Sorry for the lack of reply here. He have replicated this issue and raised it with the engineering team. At this time I don't know if or when they will take action.
ki...@iriscrm.com <ki...@iriscrm.com> #7
Than you, ek...
I hope ap... will take care of it as soon as possible.
I hope ap... will take care of it as soon as possible.
ki...@iriscrm.com <ki...@iriscrm.com> #8
Any update here?
ki...@iriscrm.com <ki...@iriscrm.com> #9
Almost a year passed, are you planning to work on this?
Thanks
Thanks
di...@gmail.com <di...@gmail.com> #10
Hello,
Thank you in advance for your help!
We are having an issue with emails being rendered differently for recipients using Outlook as their email client. Our business provides a CRM to businesses and most of our clients, approximately 60%, use Outlook as their email service for sending B2B emails. The inability to render the emails properly for all clients because HTML is being stripped during the sending operation by the Gmail API is really hurting our business.
We applied for verification and are going through the process but we wouldn't need a restricted scope if we didn't need to use XOAUTH to send emails via SMTP instead of the Gmail API.
If I am missing something, please let me know. Please fix this as soon as possible, it is very important!
Thank you in advance for your help!
We are having an issue with emails being rendered differently for recipients using Outlook as their email client. Our business provides a CRM to businesses and most of our clients, approximately 60%, use Outlook as their email service for sending B2B emails. The inability to render the emails properly for all clients because HTML is being stripped during the sending operation by the Gmail API is really hurting our business.
We applied for verification and are going through the process but we wouldn't need a restricted scope if we didn't need to use XOAUTH to send emails via SMTP instead of the Gmail API.
If I am missing something, please let me know. Please fix this as soon as possible, it is very important!
br...@mixmax.com <br...@mixmax.com> #11
Agree with the previous commenter. With Gmail's new restrictions on the oauth "restrict scope" (required to send SMTP emails), sending an SMTP email is now a very onerous workaround. It's an expensive one too! In order to get access to use the "restricted scope", your company needs to complete a security review which costs $30k+.
di...@gmail.com <di...@gmail.com> #12
Luckily we have our PCI Level 1 Compliance certification verified by a QSA every year, but that's not here or there. We literally don't need any more access than the plain Gmail Send API provides for our CRM, we just can't use the Gmail Send API as it was intended without having the HTML stripped. It's hard to imagine how the world has survived this long with stripped HTML. Help us Google! You are big and strong like Hulk!
ko...@gmail.com <ko...@gmail.com> #13
I am also working in a company that provides CRM services and the ability to send emails. This behavior is causing a lot of pain to our customers. I urge you to stop stripping these comments DOM elements from the emails they are essential part of the email. One solution could be to provide some meta tag that will disable this stripping.
Thanks,
Thanks,
br...@mixmax.com <br...@mixmax.com> #14
This issue appears to be fixed now. Can others verify this?
I tested sending a complex email with a custom DOCTYPE and HTML comments via the Gmail API. The email came through without any modifications by the Gmail API.
I tested sending a complex email with a custom DOCTYPE and HTML comments via the Gmail API. The email came through without any modifications by the Gmail API.
fe...@gmail.com <fe...@gmail.com> #15
Hi, I am testing with google-api-services-gmail v1-rev110-1.25.0 (the newest I could find) on Java and this keeps happening. How are you testing?
br...@mixmax.com <br...@mixmax.com> #16
You're right - it's still broken. I was incorrectly testing by sending an email to my own account, in which the Gmail API inexplicably preserves HTML comments in the email source. However, in the version of the email sent to the other account, HTML comments are stripped.
sp...@gmail.com <sp...@gmail.com> #17
It's definitely still 'broken'. I've been pulling my hair out for 2 days on this. I have been sending HTML emails successfully through SMTP, but since 'upgrading' to the services API I'm also losing any HTML comments in the body of the email. This is not good since I have MSO conditions needed to display the emails properly in Outlook.
I also notice the html tag I send <html lang="en" xmlns="http://www.w3.org/1999/xhtml " xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office"> is being stripped to <html lang="en">
I also tried composing the email with Swiftmailer first, but the end result is the same after passing the message off to Google.
If a GSuite user is going to be forced to stop using SMTP/less secure apps soon, is it wrong to consider this API 'cleansing' of the HTML ridiculous? Is this not valid HTML in Google's eyes? It seems to be at Litmus, etc. and has been for years.
6 years since this thread started - worries me. Assuming the rumor is true, what happens once I'm forced to use the API instead of SMTP? Boring or broken email templates I guess? I want to use the API for the 25+ accounts that need to send mail. I've put 3 days into getting it working. I don't want to have to store passwords in a database which constantly need updating. I don't want to be less secure.
https://9to5google.com/2019/12/17/g-suite-less-secure-apps/
I also notice the html tag I send <html lang="en" xmlns="
I also tried composing the email with Swiftmailer first, but the end result is the same after passing the message off to Google.
If a GSuite user is going to be forced to stop using SMTP/less secure apps soon, is it wrong to consider this API 'cleansing' of the HTML ridiculous? Is this not valid HTML in Google's eyes? It seems to be at Litmus, etc. and has been for years.
6 years since this thread started - worries me. Assuming the rumor is true, what happens once I'm forced to use the API instead of SMTP? Boring or broken email templates I guess? I want to use the API for the 25+ accounts that need to send mail. I've put 3 days into getting it working. I don't want to have to store passwords in a database which constantly need updating. I don't want to be less secure.
br...@mixmax.com <br...@mixmax.com> #18
Re: #17 - In order to use SMTP (as a workaround for this bug), you don't need to store passwords as a 'less secure app'. You can authenticate to the SMTP server using the user's OAUTH credentials. However, in order to use XOAUTH with SMTP, you'll need to complete Google's rigorous and expensive security review process.
ki...@iriscrm.com <ki...@iriscrm.com> #19
Re: #18 - We tried to pass review process to use XOAUTH for SMTP, but Google rejected our app, saying we can't let you use top level access just to overcome this API bug.
sp...@gmail.com <sp...@gmail.com> #20
Well this is ridiculous considering comments are valid HTML and every email template on the planet has [if mso] conditions in it. Is it because comments could be potentially 'spammy'? As paying customers, could that not be dealt with? How come free Gmail accounts are able to add all the comments they want to an email with basic SMTP connections? The API is flawed and considered a downgrade in my opinion - one that will eventually be forced on GSuite users when they cut us off SMTP.
I read there were 400M Outlook users in 2018. I don't know if these hacks are necessary with Office 365, but surely a few million of these users still use Outlook 2016 or older. What about the Outlook app on a phone? Sure, MS needs to get their act together when it comes to standards, but I guess Google just doesn't care since they don't bother to even discuss the issue any longer. Might be time to dump Google and go back to using email accounts on our own server.
It's been a pain as it is getting this far, only to hit a dead end.
I read there were 400M Outlook users in 2018. I don't know if these hacks are necessary with Office 365, but surely a few million of these users still use Outlook 2016 or older. What about the Outlook app on a phone? Sure, MS needs to get their act together when it comes to standards, but I guess Google just doesn't care since they don't bother to even discuss the issue any longer. Might be time to dump Google and go back to using email accounts on our own server.
It's been a pain as it is getting this far, only to hit a dead end.
la...@gmail.com <la...@gmail.com> #21
U can explicit send a "ContentType" in Raw field, Api Send:
var bodyRaw = $"From:{from}\r\n";
bodyRaw += $"To:{to}\r\n";
bodyRaw += (!string.IsNullOrEmpty(cc))?$"Cc: {cc}\r\n":string.Empty;
bodyRaw += (!string.IsNullOrEmpty(bcc))?$"Bcc: {bcc}\r\n":string.Empty;
bodyRaw += $"Subject:{subject}\r\n";
bodyRaw += $"Date:{DateTime.Now.ToString()}\r\n";
bodyRaw += $"Content-Type:text/html; charset=UTF-8\r\n";
bodyRaw += $"Message - ID: {Guid.NewGuid()}\r\n\r\n";
bodyRaw += $"{body}";
var body64 = Base64UrlEncoder.Encode(bodyRaw);
var bodyRaw = $"From:{from}\r\n";
bodyRaw += $"To:{to}\r\n";
bodyRaw += (!string.IsNullOrEmpty(cc))?$"Cc: {cc}\r\n":string.Empty;
bodyRaw += (!string.IsNullOrEmpty(bcc))?$"Bcc: {bcc}\r\n":string.Empty;
bodyRaw += $"Subject:{subject}\r\n";
bodyRaw += $"Date:{DateTime.Now.ToString()}\r\n";
bodyRaw += $"Content-Type:text/html; charset=UTF-8\r\n";
bodyRaw += $"Message - ID: {Guid.NewGuid()}\r\n\r\n";
bodyRaw += $"{body}";
var body64 = Base64UrlEncoder.Encode(bodyRaw);
jp...@google.com <jp...@google.com>
mz...@gmail.com <mz...@gmail.com> #22
This is really upsetting... we need to be able to use MSO conditions
Description
Retyped below:
Repro
Go to
Scroll down to "Try it!"
Log in with OAuth
For "userId" enter: me
For "raw" enter the result of the following node script:
generateMessage.js
var email = "From: 'me'\r\n" +
"To: bradvogel@outlook.com\r\n" +
"Subject: Test Doctype\r\n" +
"Content-Type: text/html; charset=utf-8\r\n" +
"\r\n" +
"<!doctype html>" +
"<html><body>test <!--[if !mso]>hidden from outlook<!--<![endif]--> </body></html>";
var base64 = new Buffer(email).toString('base64');
var websafeBase64 = base64.replace(/\//g, '_').replace(/\+/g, '-');
console.log(websafeBase64);
Actual result
When I view the raw message source from the email received at bradvogel@outlook.com, it comes through without the doctype or comments:
To: bradvogel@outlook.com
Subject: Test Doctype
Content-Type: multipart/alternative; boundary=089e0102fc52abed0a04ff355038
--089e0102fc52abed0a04ff355038
Content-Type: text/plain; charset=UTF-8
test
--089e0102fc52abed0a04ff355038
Content-Type: text/html; charset=UTF-8
<html><body>test </body></html>
--089e0102fc52abed0a04ff355038--
Expected result
Notice the doctype below:
To: bradvogel@outlook.com
Subject: Test Doctype
Content-Type: multipart/alternative; boundary=089e0102fc52abed0a04ff355038
--089e0102fc52abed0a04ff355038
Content-Type: text/plain; charset=UTF-8
test
--089e0102fc52abed0a04ff355038
Content-Type: text/html; charset=UTF-8
<!doctype html>
<html><body>test <!--[if !mso]>hidden from outlook<!--<![endif]--> </body></html>
--089e0102fc52abed0a04ff355038--
Notes
Sending the same message via SMTP preserves the entire message.
The doctype and comments are needed to format emails for Outlook and iOS Mail. The API appears to be taking my raw rfc822 message and converting it multipart/alternative with text and html representations, but with important content stripped out.
Does anyone know how to preserve doctype and comments in a message send through the Gmail Message Send api?