When i run my scripts as Junit test case, the browser opens up and also tries to open the provided URL. But, only the header and footer of the website is opened with the message "Cookies and Javascript Required
In order to correctly view this website, you will need Cookies and Javascript enabled on your browser. To set your browser to support these requirements, please visit your browser's help menu for the appropriate instructions."
This makes the entire script to fail as the Web elements are not displayed.
You need to provide some more information:
Does this behavior happen when you access the site normally i.e. without Selenium RC involved?
Which browser are you using?
Have you tried another browser? You can do that by changing the parameters in this line:
seleniumId = new DefaultSelenium( "localhost", 4444, "*iexplore", "http://URL");
(A useful trick is to put garbage in the browser parameter and when you run it, the error message shows all the allowable browser strings.)
Have you tried to enable cookies and Javascript? What happens then?
If you don't want cookies and Javascript enabled normally and you are using FireFox, you can set Selenium RC up to use a special proxy that does allow this (but only for Selenium tests). See here
Related
I am trying to debug a webpage with chrome developer tools and the page redirects to a pdf file after it loads. I checked JavaScript files and there is not any place that we redirect the page. I cannot find any related message in developer tool console or network tab.
I activated event Listener Breakpoints -> beforeunload but it stops at an external js file (Placeholders.js) which is not related to redirecting.
Also, preserving Logs in network tab does not help me on finding root cause of redirect.
I am wondering how can I find the source of this redirect?
UPDATE: There is not any "refresh" meta tag in the html code.
There are a couple of things you can do. You can use the Event Listener Breakpoint -> Load - unload and then when it breaks in the 3rd party library, right click and select Blackbox Script. The next time you play through the code, it should only break in your own code (assuming there are no other 3rd party libraries to blackbox).
Another option is to go to the Network tab and check the Preserve Log checkbox. This will persist all requests between page loads/navigation, so that you will be able to find the network request that returned the PDF response.
.
In Chrome's developer tools, under the "Network" tab, I can see redirect paths and HTTP status code if I check "Preserve log". See image above, where you can see the domain ap.no redirect to
www.aftenposten.no and returning a status code 301.
My problem is that it doesn't work for all sites. Are there situations where Chrome will not be able to know that a redirect has happened?
One example is amazon.com, which redirects to www.amazon.com, but I cannot see the redirect in Chrome's developer tools.
Is there another way to see the redirect info in these cases where Chrome doesn't seem to pick it up?
Try these methods to get around the issue (in order of complexity):
Use an incognito window when you load the page.
Use the extension "Cache Killer" to disable caching of data.
If all else fails, clear all browsing data from Chrome.
In this instance, only clearing browsing data helped, but I regularly use Cache Killer and incognito window when I am testing my own websites.
I am trying to use some webviewers on Filemaker WebDirect. I would like to call a script in filemaker from a button on the webviewer. It works great in pro but I'm not sure of the url protocal I need to use in web direct. What is the format I should use when trying to call a filemaker script from a webviewer in webdirect?
You'll need to test this out because I haven't tested it, but I believe that when you use a webviewer in a WebDirect solution the webviewer actually displays an iframe tag and the contents of the webviewer works like any other iframe on a webpage, i.e. it's no longer part of the WebDirect application.
You can check it out in the browser interface of your WebDirect solution by right-clicking on the webviewer and selecting "inspect element". That should open up the browser's developer tools and show you the webviewer's element in the overall HTML structure. The webviewer should be an iframe.
All of that said, if it does treat the content of the webviewer as an iframe and therefore the content of the iframe is outside of your WebDirect solution, it means that whatever communication you have from the webviewer content would need to communicate externally with your FileMaker Solution via XML custom web publishing. It would be like standing inside of your house, reaching out of a window, unlocking your front door, and grabbing something you want.
This means you would need:
Web Publishing turned on on your FileMaker Server
A user with the xml extended privileges enabled
An external IP address that you can access your FileMaker Server by
Then you could (again, theoretically I have not tried doing this) use a link that contains a url with the XML custom web publishing syntax to perform the script. You can find a description of the syntax in the FileMaker Server documentation PDF fms13_cwp_xml.pdf. I can't find a good link to the syntax online at the moment, but you could search around for it. The basic syntax outlined in the PDF is:
<scheme>://<host>[:<port>]/fmi/xml/<xml_grammar>.xml[?<query string>]
and calling a script would look like:
http://myfmsdomainname.com/fmi/xml/fmresultset.xml?-script=theScriptIwantToFire
My url structure could be off.
Anyway, it sounds like it could be a pain in the ass, but it may be a solution! Good luck!
This is tricky because you will have to communicate with the Webdirect client via FMServer!
Use the FMServer PHP interface for your webpage within the webviewer to communicate to the server. Your web page can either:
1) Directly set a value in the server that your client will monitor
2) If it has to call a script then call a script on the server, your client will still have to monitor a value. e.g. use the php API on your webpage. Setup your database connection (see the API docs in your FMServer folder for an example), then call:
$newperformscript =& $fm->newPerformScriptCommand($layoutName, 'scriptname',$scriptParameters);
$result = $newPerformScript->execute();
Your Webdirect Client will then need to monitor for that change. While Webdirect is on the layout with the webviewer, your client could use the filemaker script step to actively monitor for a change in value via a timer:
Install OnTimer [Interval:secs]
When your client detects that change that you made then perform your action.
Note: You will have to pass an ID of the client to the webviewer, and your webviewer will have to pass that ID back to the server, and your client will have to monitor for that ID so that all clients don't respond to the change. You can pass whichever client ID you choose to use to the webviewer via the URL using GET.
If your server is local then the change will be detected in one second if that is what your Install OnTimer timer is set to.
What you are doing is far from ideal with Filemaker... I suggest that you look into a different UI paradigm if possible.
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
How can I open an url in the current active browser which is been provided as a part of the mail
Example- I receive an email in my outlook.I am browsing also.If I click on the url provided in the email it must open in the current browser window which is open
I don't think that is possible with a URL. The handling of http: protocol is operating system dependent, and really shouldn't be messed with.
My default browser is FlashPeak SlimBrowser and with this as my default browser it isn't a problem since this is what it does by default. I use SlimBrowser since the web site I work on is keyed to IE and SlimBrowser uses the IE Object with any of the automatic IE junk disabled. No question about popups since they don't happen unless I click on them.
The click interface in outlook is using the API to open the default browser window. The default browser determines how it is going to handle the request.