Sometimes the rendered display of an HTML email body is incorrect. Eg:
OC gmail is rendered correct
Mobile app gmail is rendered correct
Mobile web gmail is rendered incorrect
This problem occurred only on mobile web gmail.
HTML body has a <table> tag. In the incorrect case, this table tag is broken with part of <div> tag.
I tried several times in mobile web gmail. The first email displayed correctly
but the second email displayed incorrectly.
My question is: why this happen? How do I fix it?
It's been a while since this question was asked, but I ran across the same problem myself now in 2022.
First of course I looked for the error on our end and rebuilt html/css. However, I could not find the error, it seemed to happen completely randomly.
A completely identical email sometimes looked perfectly fine, sometimes it was rendered completely broken (this can also be seen by looking at the HTML code: clean code turned into a completely chopped up array of HTML code that was definitely not ours (especially early terminated HTML tables, heaps of "empty" snippets, etc).
Then, by chance, I noticed that this phenomenon does NOT occur if I permanently delete similar emails that are ALREADY in the trash (sic!).
I have been able to narrow down the problem even further: apparently GMail bundles messages, from the same domain and with the same subject line, even if they are in the trash (however, you do NOT see this directly in the inbox, but only when you are on the (broken) email in question and refresh by dragging down (mobile) - all of a sudden, all the trash messages are additionally visible at the top of this message).
I was able to fix the problem by always writing value into the subject line that does not match any other email. This avoids the incorrect bundling and the mails look flawless again.
Cost me a lot of nerves and half a day's work - maybe I can save this for someone with my contribution.
Related
I have a bunch of emails which are written using MJML. The output HTML seems to be correct.
As an email sender, I'm using AWS SES. But after sending, all my CSS styles in an email are broken. To send an email, I'm using method ses.sendEmail.
I have tried to use CSS injected in HTML head and inline styles. Does not work.
What could be the problem with it? Thanks!
First, check your HTML. Send it through either of these free sites: https://www.putsmail.com (requires a free Litmus account; they're an established and reputable Email Service Provider, ESP) or https://useparcel.com/ (an editor for email HTML; put your HTML in the editor and use their free send feature). With putsmail, don't accept their offer to inline your CSS for you--that'll change your HTML.
When each email arrives, compare the HTML received to what you sent. Diff tools are helpful.
I just sent a 1300+ line HTML file through each of those. For both, every character arrived unchanged, except for blank lines after the </html>. That's okay with me!
Compare the rendering to what you see in one of the MJML rendering tools (maybe https://mjml.io/try-it-live or the MJML desktop app https://mjmlio.github.io/mjml-app/). Do not depend on the rendering in any one email client as fully representative of the HTML; most of them have quirks. (I'm lookin' at you, all Outlooks except Apple's! And GMail. And Yahoo!. More at https://caniemail.com/ .)
I did a little research on AWS ses.sendmail. There's important advice and information at both of these.
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-sendmail.html
https://docs.aws.amazon.com/ses/latest/APIReference/API_SendEmail.html
I found an SO ticket from a little less than a year ago that could be relevant.
AWS Amplify SES sendmail AccessDenied
Recommend you review all that. Maybe something there will improve your experience.
Last, some standard advice from the world of email HTML. If you get sendmail working, perhaps it doesn't apply.
Send your HTML using an ESP that doesn't change your HTML. For people sending lots of email, there are lots of good reasons for using an ESP. Many provide valuable services. By the same token, some ESPs change the HTML before sending; lots of us avoid them.
I hope you get it figured out. Email HTML is, as you're experiencing, anything but easy.
I am importing/creating drafts in Gmail using the Gmail API. After creation I'd like to redirect the user to the Gmail UI with the opened Draft in the composer window.
I made it work properly for https://mail.google.com/mail/#drafts?compose=[MESSAGE ID]. Other urls I found here also worked well. Gmail is doing some redirects and eventually the composer window is opened with the draft.
Now my issue:
If the user has not enabled "Conversation view" this will not work at all. The redirect will then result in https://mail.google.com/mail/u/0/#drafts?compose=new and only an empty, new composer window is shown and a new draft is created by the UI.
If I open the draft directly the ID-format is different. https://mail.google.com/mail/u/0/#drafts?compose=hJzgZpSqgLQcCWgZqnlNRzRBfMbjZVnZklzvcFxhQCdwT... and I have no idea if this format can be generated somehow.
Does anybody has an idea or experience to also make it work with this UI setting. How I can force Gmail to load the draft into the composer window?
Thanks in advance.
If you have Email Threading > Conversation View enabled
Make use of the following URL
https://mail.google.com/mail/u/0/#inbox?compose=DRAFT_MESSAGE_ID
If you have disabled the Email Threading > Conversation View option
Make use of the following URL
https://mail.google.com/mail/u/0/#inbox/DRAFT_MESSAGE_ID
Additional information
The main difference between them is that the first is treated as a conversation while the second example is not.
You can use #drafts instead of #inbox in the URL.
The number after .../mail/u/ is the session you have opened
You can retrieve the DRAFT_MESSAGE_ID by making a request to the API
You can approximately generate the compose ID by yourself, there are some examples out there (not recommended). I strongly recommend you to use the DRAFT_MESSAGE_ID instead.
This appears to still be an issue the one solution I did find was that you can find your draft directly (even though it would be the last draft) and go through multiple accounts by redirecting to
https://accounts.google.com/AccountChooser?authuser={user account}&Email={email account}&continue=https://mail.google.com/mail/#search/rfc822msgid:CAMU-31NcJCVHyGNsAycRKfuS0nMonoaZ6wFMD90Sej996qjuPQ#mail.gmail.com
You need to get your message id toi replace the area from <> from your draft. So you'll have to create the draft first. Get the google message ID, then use that with messages/get to get the Global Message Id (also referred to as message id) and then use that with a search. At this point you'll open a page with a search to a single draft but it will not be opened. Your users will have to click on the one message. Unfortunately there does not seem to be a way to have the good way work for conversation view, and this way work for non.
I tried many different URLS and nothing worked. As noted in the original question, it might work that you could link to the full URL but I see no way to get that. If you spend long enough working with an email you'll even find that ID changes so they aren't even stable within a single day.
Another solution that could work is as explained:
https://mail.google.com/mail/u/0/#inbox/DRAFT_MESSAGE_ID
But as noted this does not open the draft on the first time you go there. It seems you have to travel to that link 2 times in a row to get the message to appear. I guess you could go to the page maybe inject some javascript to go to the page again but I don't know how to do that.
I am scratching my head trying to figure out (and yes, I know there are multiple reasons this could be happening) why my AdSense Impressions have dropped to 0 after changing my site to Drupal 8.6.4.
I have installed the Drupal AdSense module, into which I've put my "pub-XYZ~~" account number.
I left it like that for several days thinking perhaps the crawler hadn't found it. Then I got cold feet and thought perhaps it wasn't working, especially since I didn't see any AdSense code appearing in the source of the page.
So I added the following code via Asset Injector into the head of the page:
<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"> </script>
<script>
(adsbygoogle = window.adsbygoogle || []).push({
google_ad_client: "ca-pub-239656292892567776",
enable_page_level_ads: true
});
</script>
(That's not my real client ID, just random numbers.)
Now I see a line of script in the head of the page:
<script src="/sites/default/files/js/js_Gc2nyd2PQaQJQwlbfhfc8Yz8TwWRl90UGM3vTenwS8s.js"></script>
And that (if I click on it) opens up the Google AdSense code I've written above.
Yet I've waited two or three days more, still not seeing any impressions, page visits, CTR (every metric on my "Performance" report is zero), and I am concerned that maybe I've done something wrong.
So does anyone know, if I'm using the Drupal AdSense module, where do I see the code?
And two, if I'm using the module, where can I see the code appearing in the source? (The Google answer doc says "You can do this by viewing the source of your site from a browser and double-checking that the ad code looks exactly like the code we provide you in your account, and includes every line of the ad code." But in the Drupal AdSense module, the only field is one for that pub-XYZ~~~ number, and nothing else, and as I mentioned, I'm not finding the code anywhere in the site when I view the source.
Three, if I'm using the module, will it mess things up to have the code above put in via the Asset Injector?
And lastly, am I just too worried and the AdSense module is doing what it should and I should check back in 10 days or 20, rather than in 5 or 7?
Thank you for any help. I had just installed AdSense (by adding it to the head of the page, this exact code) on the old site before switching to Drupal, and it was definitely working then, so I know that the issue isn't that the site isn't approved or the account's invalid or such. It WAS working fine. But after this move to Drupal 8, it's completely failed and I just don't know which link of the chain is the one I should fix. I have been scouring both Drupal docs and AdSense docs for this issue/answers and haven't found anything that seems to be the issue...and I really am hoping to know if the code side of it is correct.
Again, thank you in advance!
Okay, so for anyone else who needs this info, I'm answering my own question: I never did get the Google AdSense "auto ads" to work on my site, and am pretty sure the reason they didn't is that I was trying the "auto ads" code rather than the on-the-page, placed ads type code. I still don't know if it was simply a matter of time and the crawler hadn't found my site again, or if I had incorrect code, or what.
But I am now seeing an ad on my site, and what worked for me was:
Turn off any AdSense code in the head of the page. (I had injected the script via Asset Injector, and I disabled that.)
Make sure Drupal's AdSense module is running. DEselect the option that asks people if they wish to turn off their adblocker. The only thing I added in AdSense's main config window was my "pub-XYZ~" number.
Ditch the Google "auto ad" option and do the "Ad Units" option, creating an ad in AdSense. (AdSense > Ads > Ad Units). Do everything there and get your ad ID#.
Back to Drupal: Either create a new custom block or use one of the Drupal AdSense options to create a block on your site. If you use an Drupal AdSense option, it prompts you for the info needed to display the right ad. You'll need that ad ID# info at the very least.
Make sure that block is placed on your page. I chose "Responsive" but presumably this works for all the options. Fixed size, etc. I believe you could also (if you wanted) simply place the Google code directly into a custom block and use that. It seems people do.
If you've done it right, logged into your Drupal site, with the block placed, it will show placeholder text with your pub-# and ad ID#, in a little box. You won't see an actual ad (this is in the "Help and Information" option at the top of the AdSense module config). If you're seeing the placeholder box, it's a good sign that everything's going well with the Drupal AdSense module side of it.
Then wait, and wait, and eventually, logged out, on a private browser window, you should see the ad when the crawler finds it and other magic happens. I waited about 24 hours after setting this whole thing up before seeing an ad appear.
(Please note that this all was with a site that had a working AdSense account and had previously been getting lots of impressions for the ads. So if you don't have those aspects set up initially, none of the above will work either.)
Today we noticed new undesirable behavior from our DocuSign implementation. We are using the embedded signing approach.
Server-side when the form is loading we generate the recipient view URL. This part works fine.
Then we load this URL in an iframe on the form. The iframe only takes up a portion of the form.
Previously this was working fine, but as of today we noticed some errors. The signing ceremony still loads, but we can see errors in the console in Developer Tools. They seem to be coming from inside the iframe. When we remove the iframe the errors go away.
The console in Developer Tools, shows that a 400 (Bad Request) is being received from https://demo.docusign.net/Signing/monitoring?insession=1&ti=4c6f3176cf8841b7885f76a4b5261744 (picture below). This is not a URL that we are calling, so it must be called from within the iframe.
The signing ceremony still works from a user perspective, but this error seems to be halting client-side scripts on the rest of the page. When we remove the iframe, everything else works fine.
Any help would be appreciated. Thank you!
Embedding the signing ceremony inside an iframe is not recommended.
There are multiple techniques available for maintaining your application's state while the signing ceremony is proceeding. Why do you feel the need for an iFrame?
That said, please provide the envelope_id that had the problem and I'll submit an internal bug report.
Note, the initial url your app receives is not the final url for the signing ceremony. As part of the process, the response to the initial url is a redirect to another. That's been the case for a long time.
We finally got this working.
We changed this markup:
<iframe src="{SigningCeremonyUrl}" />
To this markup:
<iframe allow="geolocation" src="{SigningCeremonyUrl}"></iframe>
As you can see the only differences are:
Added allow="geolocation" (didn't fix the problem by itself)
Removed self-terminating <iframe /> tag and used opening and closing tags
(resolved the issue)
Notable discoveries:
The bug presented itself on 11/10/2017. It was demoed working at 8:00 or 9:00am EST, and then stopped working by the end of the day (3/4/5ish), without any changes being made on our end.
When we removed the iframe containing the signing ceremony URL, the rest of the page worked fine. Adding it back recreated the issue.
When changing the URL of the iframe to Google, the rest of the page worked fine. Changing it back recreated the issue.
When running the signing ceremony URL in the whole window (without the iframe), and with Developer Tools open, it did not throw any JavaScript errors.
When running in the iframe, and with Developer tools open, the only error we saw was the one posted in the question above.
When running in the iframe, with self-terminating html tag, we ran the following test, and only received 1 alert:
<script type="text/javascript">alert(0);</script>
<iframe ... />
<script type="text/javascript">alert(1);</script>
When running in the iframe, and with Developer Tools open, it was as if the our JavaScript wasn't even there. No scripts ran once the iframe loaded.
I've just encountered some weird behavior in Gmail that looks like some new kind of phishing attack. I got a couple shipment confirmations from Amazon today and there are these "Track Package" buttons (also I see "View Order" buttons on order confirmations) but when I click on them the page that gets opened is clearly not the correct shipper's web site.
Which looks fine but clicking on those buttons lead to bad pages. For example one of them goes to http://websro.correios.com.br. On the other it goes to USPS.com while the actual shipper (and correct link in the email body) goes to UPS.com.
I've looked at the source of the email and it all looks fine. There are no SCRIPT tags of any kind and no bogus links anywhere in the text (by which I also mean the HTML). The problem appears the same in Safari (6.1.1) and Chrome (31.0.1650.63). It looks normal in Mail (both Mountain Lion and iOS 5).
I couldn't figure out how such a button could get there and I found this feature for adding "registered" script actions to Gmail which is the only thing I can imagine would affect both Safari and Chrome.
When an order confirmation or parcel delivery email doesn't contain the necessary microdata to trigger the action, Gmail can still try to automatically extract the same information and show the button to the user as if the microdata was present.
Clearly this approach is less accurate than the one that relies on microdata, and it seems that in your case something went wrong with the automatic parsing.
No need to be worried about phishing though, as actions only show up for registered senders.