I'm sending emails from a Rails application. The emails contain links like the following:
http://critically.in/events/14-san-francisco-ca-mc-hammer-bay-to-breakers
The URL is correct when I open it on my computer, but when I read it in Mail on my iPad or iPhone, the link is converted to:
x-apple-msg-load://90CEFE95-A78E-427F-B68E-EF184F497B69/critically.in/events/14-san-francisco-ca-mc-hammer-bay-to-breakers
Make sure your links are actually fully qualified. That is, make sure they are containing the scheme and the entire domain-path.
bad: ../blah/foo/bar
good: http://example.com/blah/foo/bar
Relative URLs are not properly resolved by the iOS mail client and result into things looking like the issue you are describing.
To be absolutely certain, make sure you check the raw message text and not the results you see within other mail-clients.
Related
I have a Vue.js website with a PDF file which is included in my ultimate javascript bundle via webpack. (It's my CV.) The following build and delivery process has worked perfectly fine for me since 2017, but suddenly stopped working in iOS 14:
Build the PDF with LaTeX.
Use webpack's url-loader to include the PDF in my webpack bundle as a base64 data URI.
Load that URL into a vuex data store, and then just deliver it as a link when clicked.
For the last three years, this has worked fine: I've been able to click on the link and get a working PDF. It's been kind of random and platform-specific whether the PDF opens in-browser or shows up in a download folder, and whether it gets the filename I've asked it to get or not, but, well, that doesn't matter to me. And the core functionality of click the link and get the PDF has worked on every browser and every platform I've ever tried it on.
All of a sudden, with iOS 14, it's stopped working. Now, when I try to activate the PDF link in iOS Safari, nothing happens at all. When I do it in iOS Chrome, it produces a little popup claiming it downloaded a document, but nothing seems to actually be able to open the document. And when I do it in iOS DuckDuckGo, it just displays the base64 data URI in the address bar.
Interestingly, if I take the dataURI that DDG displays in the address bar and copy and paste it into Safari or Chrome on iOS, it actually displays my pdf. So the browsers still have the capacity to display a PDF from a data URI. It just doesn't want to do so from my link.
And my site still works as expected on the desktop. Including in Safari on the desktop. Also, it still works on my wife's phone (she's still on iOS 13). So this is clearly something Apple changed in iOS 14. But what? And how to get my site working again?
I'm guessing that Apple has changed the behavior of the renderer in iOS in some fashion to cause it to break across browsers but nowhere else (since browsers in iOS are all still required to rely on webkit, right?)
This is a pretty important feature to me. I made this decision deliberately for perceived performance---combined with pre-rendering, everything on my site, including the PDF, loads very close to instantly from the user perspective. So I'd really like to keep it.
I'm using Webpack 2.6.1 and Vue 2.3.3. This is a stable build that has been working flawlessly for three years, so I haven't felt the need to update anything except for security updates.
After searching around, I did find this Apple dev discussion which suggests that in iOS 14, Apple newly blocks redirects to data URIs. But I'm not doing a redirect, I'm actually navigating directly to the URI through a link. And the linked discussion suggests that the newly banned behavior just brings Apple in line with what other browsers already ban---but my code works in every other browser, so that can't be it.
Relevant code, to the extent it matters (though it's so basic and obvious that I doubt a simple code fix will be the answer here):
from my webpack.base.js:
{
test: /\.(pdf)$/,
loader: 'url-loader'
},
from my vuex store, in state.js
import cvURL from './assets/pdf/gowdercv.pdf';
from the component containing the link that points to PDF:
<p><a :href="cvURL" download="gowdercv.pdf"><img src="../../assets/icons/file-pdf.svg" class="cvicon"> Download in PDF</a></p>
which is loaded as a computed property to the component, i.e.,
computed: {
cvURL: function(){return this.$store.state.cvURL;},
Does anyone know how to get functionality back in iOS? Is there a workaround built in recent versions of webpack or vue for this? Thanks!
Update: after some help off SO, an acquaintance turned up this similar problem, which also came up with a solution: turning the base64 URI into a blob and passing that data url. Which also solves my problem. Though that SO doesn't have an accepted answer, so I can't vote to close my own question as a duplicate, alas.
I have problems adding a new URL when I manage knowledge base in QnAMaker.
I've tried adding this Url but I get the error:
Failed to extract QnAs from the source "URL" - Unsupported / Invalid url(s). Failed to extract Q&A from the source.
I've tested deleting the footer, publishing the page and in this case the URL works properly.
Also, I tested other very similar URLs, like this one and this has been parsed successfully.
What could be the problem?
It would appear that something with the way the questions are encoded on that page is preventing QnAMaker's services from reading the text of the question/answer pairs. In order to get those questions, I was able to copy paste the whole list:
I put them all into a word doc (or equivalent program), and then saved it as a PDF:
Then uploaded this to QnA Maker, where it was able to read the question/answer pairs just fine.
The reason I used a PDF as opposed to a .txt file is so the alternate characters (the Spanish ? for example) would render as well as the bullets from the final question that caused so much grief for the initial renderer.
After left feedback in azure site, QnA Maker Team fixed it. Now, the url is parsed properly.
I have recently moved my wordpress site from "test.xxxxxx.com" to "xxxxxx.com" They are both identical except I just want to get rid of the "test" portion of my url on my index page and all my links. They are both on the same FTP and server. I transferred my site and have the homepage url working correctly but when I click on any of the links it still says "test" in front of the url. I have tried a couple different search and replace plugins with no luck. Is there a better way to go about this?
Wordpress has a problem that it doesn't update the permalinks easily. So, maybe you will have to change the permalinks manually in the wordpress database.
Use Better Search Replace plugin in order to fix old urls in your database.
After downloading and activating the plugin, you juste have to type old url to find and by which url to replace it, in your case you have to do it twice :
test.xxxxxx.com to xxxxxx.com
and
test.xxxxxx.com/ to xxxxxx.com/
I advice to do it twice because sometimes the plugin make difference between these two (strict string comparison I think) and wil not modifiy everything with only one command
I have an email signature in which all the links work fine in every mail client except the skype one:
<span>Skype:</span> <span>Jared.Rake</span>
The link works as intended (launches the skype client) on all mail clients except gmail. Any idea why this is so?
I have the skype client installed on my system.
When you inspect the span tag(the one that contains the name, I can see the link (<a>) tag, but I cannot see the href attribute.
Any help would be appreciated.
I already see proper answer but want to make it more clear:
You can build simple "http://" link that leads to your link "skype:profile_name?add". And this http:// link will work great in any mail signature. Even in GMail.
But not all shortners will work properly. I tested it with http://is.gd/ and it works great!
So you need to:
Go to http://is.gd/
shorten your link skype:jared.rake?add and get http:// link
use this http:// link in email signature
profit! :)
More than likely it is because you are not using a real url as your href value. If it works on everything except Gmail, then it is probably a support issue in Gmail that is causing the problems. Unless there is a URL based value you could use instead, you might be out of luck.
Gmail strips out URLs that look like skype:jared.rake?add
So... make a tinyURL pointing to your Skype url, and link to the tinyURL instead :)
Additionally, if you want to rebrand your skype link you can use a subdomain that redirects to your is.gd link to keep your links branded. I created a post about this here: http://meerkat.link/skype-in-gmail-sig-using-isgd
Another alternative, in case, you own a domain name (you have a blog or personal website), is to create a PHP file containing the following lines of code:
header("Location: skype:SKYPE_ID?call");
exit();
Just replace SKYPE_ID with your ID and attach the URL of the file to your email signature. Thus, you are in total control of the link.
The protocol skype does not work on some browsers (or PC that does not have skype installed.) The best option is to add a normal link and direct it to the Skype call page. I got this information from the Add Skype link to email signature.
See the example below:
https://join.skype.com/invite/iOBDAq6GG
Don't forget to set the color of the link with style option. Because Gmail changes the default color to blue in the phone, email, and website texts.
In your example change to or similar:
<span style="color:#333;"><a style="color:#333;" href="https://join.skype.com/iOBDAq6GG">Jared.Rake</a></span>
I am currently trying to figure out an issue with an Application Protocol Handler I've created. Following the directions listed on MSDN (http://msdn.microsoft.com/en-us/library/aa767914%28v=vs.85%29.aspx), I was able to register my application, PDF Annotator, to open via a URL. The issue I am experiencing is when I try to pass a parameter along with the call. The application will open, but the file parameter that gets passed is not opening within the application.
My registry key is verbatim as dictated by MSDN. My HTML code is as follows:
PDFAnnotator:C:\path\to\file\file.pdf
The way I understood the protocol handler is it takes the URL and tries to launch it via the command line. That being said, I am able to open my pdf file in PDFAnnotator with following command in the prompt:
PDFAnnotator.exe C:\path\to\file\file.pdf
I've tried formatting the file path in the HTML differently thinking that would be the issue too. Has anyone else come across this issue or something similar?
Obligatory Update for future generations (http://xkcd.com/979/):
The reason I was doing this is because half of the PDFs my application handled would be editable while the other half were read-only. I was trying to keep the read-only ones in browser with the Acrobat plugin (I'm targeting chrome only) while the protocol would allow me to set the links of the editable ones to open with Annotator. I tried, on whim, to reverse this (setting the default to Annotator and creating a protocol for Acrobat). I did this, first by trying Acrobat's URI Scheme (acrobat://), which didn't work outside of opening Acrobat. Then, I tried creating a protocol for Acrobat. When that fired off, it gave me an error stating the path was wrong for the file name, path name, or volume. So, progress? I'm giving up on this for now as other priorities have come up, but hopefully this helps somebody down the road.