I have a link on my website to open up a text with a new message. The following link works on most Android phones:
sms:5555555555?body=JOIN
But on the Galaxy S7, the ?body=JOIN parameter is interpreted to be a part of the phone number itself, as if the letters we input on a keypad. So the example above, would open up a new message to the phone number: 555555555526395646 and an empty message body.
I don't have an s7 myself so it's difficult to debug. Any ideas what else I can try to make it work as expected on the s7?
Different platform wise it will work differently. check challenges section on this link
For iOS same problem here and for android its partially support
As Rajesh suggests, this will widely differ for different platforms, and sometimes for different version. This is the structure you would use for Android :
Link
And for iOS :
Link
Keep in mind that these formats can change (in your example the format works on most Android devices, but not on an S7; in other examples, the format was different for sending SMS in iOS 7 and iOS 8). Also, note that the app which handles the SMS URI can be changed on Android, and manufacturers take advantage of it (which may be what caused the malfunction on the S7 in the first place). So tweaking with exceptions can be a little hacky.
Otherwise, you could consider using an existing package like sms or a service like Twilio.
Although I cannot reproduce the behaviour, here are some links from the RFC's addressing the sms: and tel: URI schemes.
Under section 2.2 of RFC 5724 - URI Scheme for GSM Short Message Service is the formal definition of the URI, which says that the sms-recipient (the phone number you want to send the sms to) must be equal to telephone-subscriber which is defined in RFC 3966.
Although, your URI seems to work correctly on most of the devices (quirk? edge-case?), you must cross-check the format with the one described in the RFC to be sure that it's standards-compliant. Or maybe it's possible that it's a software/parser bug on the device itself! (not sure though...)
Related
Because the canvas bug of samsung stock browser, my program will cause error.
(http://code.google.com/p/android/issues/detail?id=39247)
So I want to disable canvas on all Samsung stock browser.
Could I detect it by navigator object or other way?
I found the same question, but it's solution looks like not perfect
(javascript - regex matching devices on user agent)
Wiki shows Samsung has more models.
(http://en.wikipedia.org/wiki/Samsung_Galaxy_S_III)
You can simply do this
var isSamsungBrowser = navigator.userAgent.match(/SamsungBrowser/i)
The following regex covers almost all Samsung mobile devices.
if(navigator.userAgent.match(/SAMSUNG|Samsung|SGH-[I|N|T]|GT-[I|N]|SM-[A|N|P|T|Z]|SHV-E|SCH-[I|J|R|S]|SPH-L/i)) {
console.log("it's Samsung");
// your code for Samsung Smartphones goes here...
}
using the userAgent is enough to detect this bug. Look for the string 534.30. For instance:
if (window.navigator && window.navigator.userAgent.indexOf('534.30') > 0) {
// Clear the canvas a different way because they are using a known-bad version of the default android browser
}
I think it can be ok:
const isSamsungBrowser = navigator.userAgent.indexOf('SamsungBrowser') > - 1
Some samsung user agents have the word "samsung" in them. If you find "samsung" in the user agent string it's a good indicator. However, most samsung user agents I looked at didn't contain the word samsung. But there is a different check, all samsung model numbers (so far) are in the format "GT-xxxxxx" so we check for the user agent having "android" in, followed by "GT-" somewhere in the UA. (or the word samsung...) This is obviously a little slack but seems to catch them ok so far....
I've recently got an email from Google, saying that they are going to ban my AdSense account because I'm sending Personally Identifiable Information to them with my Google AdSense tag requests. It says that around 1% of requests from my website have a referrer of:
some_user#my_website.com/some/subpage
and they consider some_user#my_website.com to be PII (even though it can be completely made up abcd1234#my_website.com). More on this here: https://support.google.com/adsense/answer/6163366?hl=en .
I never link to this kind of URLs (the only form I use is my_website.com/some/subpage), but I guess my users sometimes enter it manually (since product-wise my website is providing an email service, it may seem reasonable by some logic).
I figured URI of some_user#my_website.com/some/subpage is legal since http basic auth allows for specifying user like this. When I entered it manually to Firefox, some_user# disappears from the location bar but in the Net panel of Firebug I can see all files are indeed requested from some_user#my_website.com/some/subpage and that's how Google sees it too.
I though that as a brute-force solution even something like:
if uri contains '#':
redirect to my_website.com
would do.
I'm using NGINX/UWSGI/Python Paste + JS. I've tried to implement the above condition both on server side and in JS, but my URI always says my_website.com/some/subpage even if I manually put some_user#my_website.com/some/subpage in the browser address bar.
I've also tried configuring basic_auth in NGINX to disallow providing any user but with no effect.
How do I get rid of these requests?
How do I get the FULL URI (with some_user#) in JS? I tried document.URI and window.location.href but they didn't contain the user part...
Apparently presence of user# part in the URI can be detected by examining window.location.href. I haven't noticed it before since window.location.href only contains user# in Webkit-based browsers (e.g. Chrome, Opera, Safari) but not in Firefox!
To resolve the problem I've added a check on that in JS + a JS redirect to an URL without user[:password]#.
Hopefully Google uses the same variable to figure out referrer for the ad requests, so it get PII only from Webkit browsers & fixing it for Webkit suffices. Will keep you posted.
window.crypto && window.crypto.signText
Since firefox 33 , Mozilla no longer supports this feature.
However there's almost no information about the alternative to window.crypto.signText on the web or is there any at all?
Does anybody have a clue on this matter, appreciate the kind help?
To enable signText temporary, you should type a new url in the address bar about:config and then right click -> New -> String.
Type dom.unsafe_legacy_crypto.enabled -> hit Enter -> select True.
Restart your Firefox browser.
Relevant issue is https://bugzilla.mozilla.org/show_bug.cgi?id=1083118.
Here's the deal with my investigation on the matter:
Mozilla removed the old API in their version because of security issues and not being official standard - https://developer.mozilla.org/en-US/docs/Archive/Mozilla/JavaScript_crypto
No back compatibility , nothing.
In future it is going to be replaced by the Web Crypto API
http://caniuse.com/#feat=cryptography
http://msdn.microsoft.com/en-us/library/ie/dn302338(v=vs.85).aspx
which is a total nonsense because it doesn't support certificates.
If you want to enable it in Firefox 33 type about:config as URL and then set:
dom.webcrypto.enabled = true
Finally here's more on the problem:
http://www.youtube.com/watch?v=MNzTCoxr2ek
So millions of users are left without the online signing with imported certificates under Firefox and there's nothing on the horizon coming for any of the browsers.
Happily several people packaged the deprecated crypto.signCode() as firefox plugin. I personally use signtextjs but there are few more to choose from.
see here: https://developer.mozilla.org/en-US/Firefox/Releases/33/Site_Compatibility#Security
looks like the replacement is Web Crypto API.
Chrome mobile has recently added the ability to add to home screen, similar to iOS. This is cool but it doesn't support it as well as iOS - it doesn't support window.navigator.standalone so you can't detect whether you are running as a standalone app.
The reference says:
How can I detect if the app is running as an installed app?
You can’t, directly.
Notice it says "directly". My question is can we do it indirectly? Is there some tricky way to make an educated guess?
This answer comes with a huge delay, but I post it here just for other people who are struggling to find a solution.
Recently Google has implemented the CSS conditional display-mode: standalone, so there are two possible ways to detect if an app is running standalone:
Using CSS:
#media all and (display-mode: standalone) {
/* Here goes the CSS rules that will only apply if app is running standalone */
}
Using both CSS and Javascript:
function isRunningStandalone() {
return (window.matchMedia('(display-mode: standalone)').matches);
}
...
if (isRunningStandalone()) {
/* This code will be executed if app is running standalone */
}
If you need more information, Google Developers has a page dedicated to this topic: https://developers.google.com/web/updates/2015/10/display-mode
iOS and Chrome WebApp behaves different, thats the reason i came to following:
isInWebAppiOS = (window.navigator.standalone === true);
isInWebAppChrome = (window.matchMedia('(display-mode: standalone)').matches);
Same as here: Detect if iOS is using webapp
For the IOS we have window.navigator.standalone property to check..
But for Chrome on Android, it doesn't support this property. Only way to check this is by calculating screen width and height.
Below is the code to check that:
navigator.standalone = navigator.standalone || (screen.height-document.documentElement.clientHeight<40)
I got reference from below link:
Home Screen Web Apps for Android Thanks to Chrome 31
An old question but significantly better solutions available today for Chrome Android.
One of the ways(cleanest IMO). You may add Web App Manifest with a 'start_url' key with a value that adds a query string parameter to your usual homepage.
ex:- if homepage url is https://www.example.com.
in Web App Manifest set
"start_url": "https://www.example.com/?user_mode=app"
Google's guide about Web app manifest:https://developers.google.com/web/fundamentals/engage-and-retain/web-app-manifest/
With IOS, localstorage for the standalone and web mode are different. With android KitKat and Chrome, when you save a value in localstorage on the web version, you're able to retrieve it in standalone mode.
So, you just have to save document.documentElement.clientHeight to localstorage when user is browsing the web version (before adding to homescreen). Then, just compare the current value of document.documentElement.clientHeight with localstorage value. If the current value is >, it's standalone mode.
I tried it on several devices.
For Google Chrome (Android) from version 39 onwards with web application manifest (json) and in case, it is a single page application, I use this 'trick':
In the manifest.json I put: "start_url": "standalone.html".
Normally it is (in my case index.html), but from index.html I make an identical clone: standalone.html (or whatever you fancy).
Then, to check, I use Javascript like this:
var locurl = document.location.href;
if (locurl.indexOf("standalone.html") != -1) {
console.log("app is running standalone");
} else {
console.log("app is running in normal browser mode");
}
That works.
It might work too in Google Chrome (mobile) version 31-38 with this meta-tag:
<meta name="application-url" content="http://my.domain.com/standalone.html">.
Not tested, yet.
There is no 'proper' way to do it on Android, hence no API support yet.
The workaround we used in my company -
On first login, store screenheight in localstorage.
By screenHeight i mean document.documentElement.clientHeight before page loads, since then doc grows and its not accurate measure for real available screen height.
Whenever user logs in next time - check current screenheight vs stored - if it becomes bigger, the user has gone fullscreen.
There is no scenario upon which it can become smaller, IF YOU DO store FIRST TIME value for screen height.
Caveat - user that will clean cash.
We chose to ignore that, since most users don't do it or do it relatively rarely, and it will suffice(in our opinion) for some time until there will be API fix for this( hopefully there will be :) )
Option b - check available screenheight vs device screen height, the matchup for a few test devices & browser modes showed some pattern( available height < 70 in webapp) - i strongly believe a wider comparison can get values that will suffice for 90% of devices in 90% cases.
All of this is a workaround, of course, i m not pretending its a solid stable way to get to desired functionality - but for us it worked, so i hope this helps somebody else who fought this bug(cant call missing such crucial api feature other way). Good luck :)
To detect if it's running on MIT AI2 webview:
if (typeof window.AppInventor!="undefined") { return true; }
you have to work with window.navigator.standalone, this API is only works on mobile IOS safari, not event on your macbook or iMac's safari...
Below is the HTML
<a id="LnkEmail" onclick="doMailto('d#s.com');" href="javascript:void(0);">
<span id="LblEmail">ABC</span></a>
Javascript
<script type="text/javascript">
function doMailto(EmailAddress) {
document.location.href = window.open('mailto:' + EmailAddress, 'new window');
}
</script>
In FireFox, it opens the image on clicking the span like below.
Query - In IE 8 - Nothing happens on clicking it. Any Idea ?
The popup selection feature is native to Firefox and is NOT an available feature in Internet Explorer, as Internet Explorer handles association directly from Windows, your operating system. So, whichever program is meant to handle mailto: links on your computer is what will open (most typically, Outlook Express). There is no consistent way to avoid this as you cannot control what a user decides to open that protocol with. MY suggestion is to write a POST asp.net contact form. I'm not an ASP.NET developer myself, but I found this tutorial for you: http://www.jimcobooks.com/tutorials/emailform1/default.aspx
To test this theory: try finding a computer without any mail client (no outlook, outlook express, etc.) Internet Explorer will then prompt for a program to open the protocol.
Another test (the way I tested) I set up Google Chrome to handle all mailto:requests and forward them into my Gmail Webmail interface. When I tested your link, and modified your windowname in jsfiddle ( http://jsfiddle.net/sHYW8/2/ ), Windows asked me if IE could open Google Chrome to Handle the Protocol.
Short answer: what you ask is technically impossible unless you force all your users to install a third party addon for IE. This is the result of Internet Explorer being a part of the Windows Operating System, and Mozilla Firefox is a third party browser that is forced to handle protocols in its own way.
UPDATE
I found a jQuery plugin that uses the API for Gmail, Yahoo! and MSN. It's not a popup, but more of a rollover. I think this is going to be your closest bet.
http://kevin-cantwell.github.com/webmailto/
Good thing for you is that implementation seems easy enough. I would look at the bottom example, it looks pretty slick.
try this:
function doMailto(EmailAddress) {
document.location.href = 'mailto:' + EmailAddress;
}
I think your IE is preventing pop up windows created by javascript.
Just to be clear...
Adriano's suggestion of just using a normal html tag would also work.
Like this:
<a id="LnkEmail" href="mailto:d#s.com">
And as Vishal and Kyle Macey tried to explain:
That "Launch Application" window that pops up in Firefox... that is not a window you can create from a web page. That is Firefox's own window that it shows when a mailto: link is clicked. IE does not offer the same type of window. It usually just opens your default mail client (in your case it would probably be Outlook).
and finally...
Javascript is not the same as JQuery.
JQuery is written in Javascript but JQuery is NOT Javascript.
For IE 7 and 8 only you can't use any space in the window name. Try to change your code to:
window.open('mailto:' + EmailAddress, 'Mail');
If you really want such a list there is a way with pure javascript although it might not be the exact same experience as you currently have in firefox. What you could do is create a modal dialog with javascript showing a number of popular webmail clients and an option "default system client" instead of "Microsoft Office Outlook". The "Choose an Application" would be impossible to include as well. Next, if the user selects the native client you would simply trigger a mailto link as you currently do and in case the user selects for example gmail you trigger a window open of a link along the lines of
https://mail.google.com/mail/?view=cm&fs=1&tf=1&source=mailto&to=info#example.com&body=the+body+of+your+message
with your own variables of course from your mailto link. You would have to figure out the relevant links for different webmail services yourself, but as far as I know, most have these kind of links and gmail and yahoo have for sure.
Below is the working code as you mention
window.open('mailto:' + EmailAddress, 'newwindow');
its working but like FF IE not provide you option to choose mail engine.
If you want to run your code you have to set the default program for mail using set default program.
And you can set only Outlook as the default program. In out look you can bind any thing like yahoo or gamil that way you can use your mailto code for IE.
I think You have to doing coding for that because IE not provide any add on like FF.
For That first you have to chekc if default client mai lis there or not by following code
RegistryKey hkey = Registry.ClassesRoot.OpenSubKey(
"mailto\shell\open\command", false);
if this key is null then no default client is there. so you have to show the mail provides list on popup. and selected provider you have to set as default client mail.
http://msdn.microsoft.com/en-us/library/microsoft.win32.registry.classesroot(v=vs.90).aspx
using above link you can find list of mailto registered on machine for list display.
http://www.pcreview.co.uk/forums/re-add-dword-value-registry-t1401434.html
this link show how to set value in registry.
then execute your mailto code.
The mailing list is an utility features provided by Firefox only. You may or may not not find one software's feature on another similar one. If you don't, you should settle for a work around.
Try to remember that in firefox once the user selects a default mail client, you will not get the popup anymore. So there is no use of attempting to create a solution, that is not going to be permanent.
To trim down your requirement, you are trying to select the mail client of the user. But a website cannot changed the system settings of the user, its simply not allowed. Why? Because it opens many vulnerabilities to the user, if this was somehow allowed.