Develop Reference

sms: link with alphabetical parameters interpreted as numbers on Samsung Galaxy S7

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...)

Firefox never resolving navigator.mediaDevices.getUserMedia()

I am trying to use the new Promise-based WebRTC/Media tools, to get feedback if the user allowed access to the camera and/or microphone as documented here https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia
The following code-snippet, simply injected with the browser's developer tools, does never fullfill the Promise on Firefox when access is granted, yet on Chrome it works as expected.
(tested with Firefox 53 32-bit, Chrome 59 64-bit)
navigator.mediaDevices.getUserMedia({
"audio": true,
"video": true
})
.then(() => console.log("OK!"))
.catch(() => console.log("NOPE"))
It appears that the Promise is pending forever.
Steps to reproduce:
open any https encrypted page (so firefox doesnt complain about that)
open the developer tools, get to the console
paste the code snippet from above
allow camera/microphone access in the popup
nothing
Is this a bug in Firefox or is something wrong with the code snippet?
To comply with the MDN documentation, i've also tried to use the good'ol functions instead of ES6 arrow functions - with the same effect.

Seems to be fine in Firefox 53.0.3. The output I get is as follows:

After disabling all addons (especially NoScript - even after setting "scripts globally allowed" to true) it appears to run just fine.
Sorry for the unnecessary question then, i guess, and thanks for reconfirming me, that the problem was not Firefox itself, so got on the right track to find the solution!

How to detect if web app running standalone on Chrome mobile

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...

Is it possible to monitor all network traffic in a Safari Extension?

Since the newer versions of Safari (I'm running version 5.2) seem to have removed the "Activity" viewer from the "Window" menu, I would like to write an extension to have this feature back. However, in order to do that I think that I will need to be able to see what URLs are being requested in that window/tab. For Chrome, there is a "webRequest" API that does this, but I can't seem to find what I'm looking for to do this in Safari. Would someone please tell me if this is possible, and if so, where should I look next? Thanks in advance.
So far, the most I've been able to get is using an injected start script like the one below:
function trackRequests() {
console.log(event.timeStamp + ": " + event.type, event.url, event);
}
document.addEventListener("beforeload", trackRequests, true);
However, this does not provide enough for the features I'll need for this. For example, if a URL is specified without a protocol e.g. "//example.com/file.txt" that is all this handlers sees; it doesn't know what actual protocol was used or if the request was allowed.
It appears that some people on the Apple discussion forums, MacDailyNews, and ArsTechnica have expressed a desire to have this feature back in Safari as well. Here's a link to another discussion on MacRumors.com and another.

On windows I would use Fiddler but since you appear to be using a Mac here are some alternatives:
http://alternativeto.net/software/fiddler/?platform=mac
Hope this helps!
Cheers!

Is "localStorage" in Firefox only working when the page is online?

So I'm toying around with HTML 5 and the localStorage and I'm noticing that my values only get stored when I run the page in Firefox on the local host (i.e. http://127.0.0.1:8000/test/index.html), but when I run the file locally (file:///C:/test/index.html) my values don't get stored. Safari 4 has no problems with both setups.
So does anybody know if this is by design -> DOM Storage on the Mozilla Developer Center
(Firefox 2 permitted access to storage
objects higher in the domain hierarchy
than the current document. This is no
longer allowed in Firefox 3, for
security reasons. In addition, this
proposed addition to HTML 5 has been
removed from the HTML 5 specification
in favor of localStorage, which is
implemented in Firefox 3.5.)
Or if there is a workaround?
I wonder because offline storage that works only online sounds silly :P
If anybody wonders, the code is as easy as it gets:
function save()
{
localStorage.setItem('foo','bar');
}
function load()
{
var test = localStorage.getItem('foo');
alert(test);
}

It seems a bug: Bug 507361 - localStorage doesn't work in file:/// documents
Hope is fixed soon!
2011-09-13: Bug fixed, implemented in 'Mozilla8'. I tested this with Firefox 8 and it works now.

Well, the linked document does say that
localStorage is the same as globalStorage[location.hostname], with the exception of being scoped to an HTML5 origin (scheme + hostname + non-standard port)
I don't want to claim that I understand 100% what that means, but the bit in brackets would suggest that the URL needs to have certain properties - in particular that the scheme and hostname are what Firefox considers an HTML 5 origin. I suspect that file:/// URLs don't match this, while your http://127.0.0.1/ does.
edit: Looking at the W3C's description of the Origin property, step 7 looks like it might be causing the problem. Depending on how the localStorage handling is implemented, it may be expecting a 3-tuple as returned by step 12, but for a file:// URL the return value may be just about anything.
So, er, I suppose it is by design. On reflection, chances are that this isn't really by design; there's no reason why localStorage shouldn't work for file:// URLs. It might just be a case of the output of one browser-specific implementation not matching the expectations of another.
As for workarounds, would globalStorage not do what you want here?

As of Oct 5 2020, localStorage on Firefox seems to be broken again. Try this:
Download Mozilla demo page: https://mdn.github.io/dom-examples/web-storage/
Change the animal/color to something other than default.
close the page's tab (or the browser).
Download the page again. It's back to defaults. (Firefox 81:0 et.al.)
Even worse, if you do step 1 & 2 above and then open another copy of the demo in a new tab, not only does the new tab not get the saved data, but the original demo page (refresh it) has gone back to the defaults; as though the new tab STEPPED on the saved data.