I'm developing website with a lot of HTML5 and CSS3 features. I'm also using iframe to embed several content on my website. It works fine if I open it using Chrome/Firefox/Safari mobile browser. However, if I share on facebook (post/page) and I opened it up with Facebook application with Facebook Internal Browser, my website is messed up.
Is there any tools or way to debug on Facebook Browser? Thanks.
This is how you can do the debugging yourself. It's painful, but the only way I've come across so far.
tl;dr Get the Facebook App loading a page on your local server so you can iterate quickly. Then print debug statements directly to the page until you figure out what is going on.
Get a link to a page on your local server that you can access on your mobile device (test in mobile safari that it works). See this to find out your local IP address How do you access a website running on localhost from iPhone browser. It will look something like this
http://192.xxx.1.127:3000/facebook-test
Post that link on your Facebook page (you can make it private so your friends aren't all like WTF?)
Click the posted link in the Facebook mobile App and it will open up in Facebook's mobile browser
Since you don't have a console, you basically need to print debug statements directly to the page so it is visible. Put debug statements all over your code. If your problems are primarily related to CSS, then you can iteratively comment out stuff until you've found the issue(s) or print the relevant CSS attributes using JavaScript. Eg something like (using JQuery)
function debug(str){$('body').append("<br>"+str);}
Quite possibly the most painful part. The Facebook browser caches very aggressively. If you are making changes and nothing has happened, it's because the content is cached. You can sometimes resolve this by updating the URLs, eg /facebook-test-1, /facebook-test-2, or adding dummy parameters eg /facebook-test?dummy=1. But if the changes are in external css or js sheets it sometimes will still cache. To 100% clear the cache, delete the Facebook App from your mobile device and reinstall.
The internal browser the Facebook app uses is essentially a uiWebView. Paul Irish has made a simple iOS app that lets you load any URL into a uiWebView which you then can debug using Safari's Developer Tools.
https://github.com/paulirish/iOS-WebView-App
I found a way how to debug it easier. You will need to install the Ghostlab app (You have a 7-day free trial there, however it's totally worth paying for).
In Ghostlab, add the website address (or a localhost address) you want to debug and start the session.
Ghostlab will generate a link for access.
Copy that link and post it on Facebook (as a private post)
Open the link on mobile and that's it! Ghostlab will identify you once you open that link, and will allow you to debug the page.
For debugging, you will have all the same tools as in the Chrome devtools (how cool is that!). For example, you can tweak CSS and see the changes applied live.
If you want to debug a possible error, you can try to catch it and display it.
Put this at the very top of your code:
window.onerror = function (msg, url, lineNo, columnNo, error) {
var string = msg.toLowerCase();
var substring = "script error";
if (string.indexOf(substring) > -1){
alert('Script Error: See Browser Console for Detail');
} else {
var message = [
'Message: ' + msg,
'URL: ' + url,
'Line: ' + lineNo,
'Column: ' + columnNo,
'Error object: ' + JSON.stringify(error)
].join(' - ');
alert(message);
}
}
(Source: MDN)
This will catch and alert your errors.
Share a link on Facebook (privately), or send yourself a message on Facebook Messenger (easier). To break the cache, create a new URL every time, e.g. by appending a random string to the URL.
Follow the link and see if you can find any errors.
With help of ngrok create temporary http & https adress instead of your ordinary localhost:3000(or other port) and you could run your app on any devices. It is super easy to use.
and as it was written above all other useful information you should write somewhere inside div element (in case of React I recommend to put onClick on that div with force update or other function for getting info, sometimes it helps because JS in FB could be executed erlier than your information appears). Keep in mind that alerts are not reliable, sometimes they are blocked
bonus from ngrok that in console you will see which files was
requested and response code (it will replace lack of network tab)
and about iFrame.If you use it on other domain and you rely on cookies - you should know that facebook in-app browser blocks 3rd party cookies
test on Android and iOS separately because technicaly they use different browsers
Related
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.
I'm building a website using WordPress as a backend, and AngularJS as the frontend. I'm using the WordPress JSON API to get my data to the front-end.
https://wordpress.org/plugins/json-api/
The problem
I'm using AngularJS to get my data from the WordPress JSON API. I have created the following service:
this.getPage = function ( slug ) {
return $http.get('wordpress/api/get_page/?slug=' + slug)
}
I use this service in my controller to get the current page like this:
HTTPService.getPage('home')
.success(function ( data ) {
$scope.page = data.page;
console.log(arguments);
})
.error( function () {
console.log(arguments);
})
This is working fine in all browsers, except for Safari on iOS. On Safari on iOS I get the following response when I log the error arguments:
This is the safari debugger which showed when I connected my iPhone to my Mac. The error response which I get is error code 0..
What I have tried so far
I have set Access-Control-Allow-Origin "*" in the .htaccess file, but this doesn't seem to work. The request is done on the same domain with a relative URL, so I don't think that this is the problem.
So, does anyone know why this is not working on Safari (iOS)?
EDIT
Some extra information as requested:
I'm pretty sure that this is due to the fact that Safari is the only browser that has the policy of blocking "3rd party cookies and other website data" by default. Actually, this issue shouldn't be exclusive of Safari iOS, it should also happen with Safari on your OSX. I'm pretty sure that if it's not happening in your MacBook is because one day you changed the default settings of the "Privacy".
You can try this, open Safari, go to "preferences" and under the tab "Pricacy" check if you have the option: "Block cookies and other website data" set to "From third parties and advertisers". This is the first, and the default option in the modern versions of Safari.
In your MacBook it will look like this:
And in iOS it will look like this:
Just to confirm that this is in fact what's causing your issue: change this setting to "Never", clear the cache and try to reproduce that problem again. I'm quite confident that you won't be able to reproduce it.
Now, if you set it back to "Block cookies and other website data: From third parties and advertisers" and you first clear the cache, you will have that problem again (with either iOS or OSX). After you've confirmed that this is the cause of your problem, set this setting back to "From third parties and advertisers", so that you can reproduce and address the problem with the default settings.
Bare in mind that every time that you want to re-test this issue you will be better off clearing the cache of Safary. Otherwise it could happen that Safari decides that the site serving the API can be trusted and you won't be able to reproduce the issue. So, just to be sure, clear the cache every time that you test this.
I believe that the root of this problem is that Safari wants to make sure that the user has had a direct interaction with the page that it's serving the "3rd party content" before the main page loads that content.
I would need to know more about your project in order to suggest an "optimal" solution. For instance: will the final app be integrated under the same domain as the API? Because if that's the case, you shouldn't have that issue when you go to production. I mean, if the app that you are developing will be hosted under: http://whatever.yourDomain.org and the API is going to be part of that same domain (yourDomain.org), then you shouldn't have that issue at all in production.
On the other hand, if you need to have have the API hosted under a different domain, then you will have to find a way to "trick" Safari. Have a look at this:
Safari 3rd party cookie iframe trick no longer working?
And this:
http://www.allannienhuis.com/archives/2013/11/03/blocked-3rd-party-session-cookies-in-iframes/
I hope that this helps.
Is there any standard way of debugging Javascript on a webpage that's being accessed from a htmlLoader component inside of an Adobe Air application?
I have a web app built using Javascript that works perfectly within the browser. One of the main elements of its user interface is that when you right click on an image, a context menu appears specific to that image.
I'm trying to embed access to this web app within an Adobe Air application. To this end, I've added an htmlLoader that accesses the URL and displays it in the Air application. It works perfectly - except that, after navigating away from the web app's landing page, the context menus no longer display when an image is right-clicked.
I'm thinking this must have something to do with the Javascript when run in Adobe Air (all other aspects of the web app continue to work), but it's hard to go about figuring out what's wrong when the Javascript works perfectly in IE/Chrome/Etc but not inside of Air. I'm very doubtful anything like Firebug exists for Flash Builder/Adobe Air, but it seemed worth asking.
There is AIR Introspector. It's a script that you add to the app (remove during production) that acts like Firebug Lite. It has a console and HTML structure viewer.
And I think you can also use Firebug Lite as well.
I know this thread is old, but it is still accessed from google so I'll list this as an alternate answer:
window.onerror = function(msg, url, line) {
// You can view the information in an alert to see things working
// like so:
alert("Error: " + msg + "\nurl: " + url + "\nline #: " + line);
// TODO: Report this error via ajax so you can keep track
// of what pages have JS issues
var suppressErrorAlert = true;
// If you return true, then error alerts (like in older versions of
// Internet Explorer) will be suppressed.
return suppressErrorAlert;
};
Credit goes to another SO thread that I've lost track of I'm afraid.
I have a classic ASP web page that used to work... but the network guys have made a lot of changes including moving the app to winodws 2008 server running iis 7.5. We also upgraded to IE 9.
I'm getting a Permission denied error message when I try to click on the following link:
<a href=javascript:window.parent.ElementContent('SearchCriteria','OBJECT=321402.EV806','cmboSearchType','D',false)>
But other links like the following one work just fine:
<a href="javascript:ElementContent('SearchCriteria','OBJECT=321402.EV806', 'cmboSearchType','D',false)">
The difference is that the link that is failing is in an iframe. I noticed on other posts, it makes a difference whether or not the iframe content is coming from another domain.
In my case, it's not. But I am getting data from another server by doing the following...
set objhttp = Server.CreateObject("winhttp.winhttprequest.5.1")
objhttp.open "get", strURL
objhttp.send
and then i change the actual html that i get back ... add some hyperlinks etc. Then i save it to a file on my local server. (saved as *.html files)
Then when my page is loading, i look for the specific html file and load it into the iframe.
I know some group policy options in IE have changed... and i'm looking into those changes. but the fact that one javascript link works makes me wonder whether the problem lies somewhere else...???
any suggestions would be appreciated.
thanks.
You could try with Msxml2.ServerXMLHTTP instead of WinHttp.WinHttpRequest.
See differences between Msxml2.ServerXMLHTTP and WinHttp.WinHttpRequest? for the difference between Msxml2.ServerXMLHTTP.
On this exellent site about ASP you get plenty of codesamples on how to use Msxml2.ServerXMLHTTP which is the most recent of the two:
http://classicasp.aspfaq.com/general/how-do-i-read-the-contents-of-a-remote-web-page.html
About the IE9 issue: connect a pc with an older IE or another browser to test if the browser that is the culprit. Also in IE9 (or better in Firefox/Firebug) use the development tools (F12) and watch the console for errors while the contents of the iFrame load.
Your method to get dynamic pages is not efficient i'm afraid, ASP itself can do that and you could use eg a div instead of an iframe and replace the contents with what you get from the request. I will need to see more code to give better advice.
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.