I'm writing a ajax chatting webapp, just to test working with GWT.
To simulate server side push of chat messages from the server to the browser, I have a XHR request running behind. It all works fine - except on Chrome, the browser is displaying a loading icon (a spinner) because of the XHR request on background.
Is there any way to avoid this? I've tested it in Firefox, and it doesn't display such behavior.
EDIT - I found the solution. http://groups.google.com/group/google-web-toolkit/browse_thread/thread/a0330cb47e05c485?fwc=2
quoting the GWT groiup post:
Chrome shows the loading indicator if connection was made immediately
from the "body onload()", i.e. from onModuleLoad().
Chrome shows the loading indicator if connection was made immediately from the "body onload()", i.e. from onModuleLoad().
No, there is now way to disable this.
All AJAX requests cause Chrome to display this. I'm guessing it's for security reasons. (The user is aware of any AJAX requests that he/she might not be aware of.) Also, it indicates that data is being fetched - a type of status indicator.
Related
In my project I'm sending GET request to the server and what I found my every request is displaying in the xmlhttprequest log (attached screenshot) and when you open this with the browser it will show all the data. I'm going to create an API key method for my rest API, While it also takes time, for now, I want to hide logs from the console. So my question is how to hide such types of the log from my chrome console.
From my point of view it is not possible to hide any request your are sending with ajax, and another thing is that it is not compulsory to use chrome browser to use, user can use different browser, showing console log is like this is in-build functionality, normal user will not see console log. if your are worried about developers there are many plugin(like firebug) which they can use to monitor your request/response flow. so if you find any way to hide them it's not 100% solution.
my advice would be you use server side method to call your API if possible.
or second thing you can do is call console.clear(); function after calling ajax function(possible after success/fail).
you can hide such messages in Chrome in Console > Settings
(F12 > F1)
Tick [x] Hide network messages
Untick [] Log XMLHttpRequests
You can change it in the Console Settings > Hide Network
Hide Network on Console Settings
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
Is it currently possible to view the body of the message being sent by a COMET event using Chrome Developer tools? I'm simply looking at COMET Clock sample here by Play Framework - http://www.playframework.com/documentation/2.2.x/Samples. When I enable the developer tools and go to the event-stream object, I can only see the request and response headers. No body or message can be viewed anywhere. Is this currently even possible? Nothing shows up under WebSockets, but I'm fairly sure this example is not using WebSockets, so that makes sense.
No. It is not possible for HTTP streaming (which I think it is your case) as March 2014 (hopefully they change this in the future)
Google Devtools only shows the response when the connection is closed.
In the case of web-sockets you do see live data.
But! modern versions of Firebug can show live data streaming. So I recommend you get Firefox and install the Firebug addon.
((Ahh firebug, it used to be all we had. Poor forgotten guy. But it still has nice things Chrome lacks!))
Cheers.
You can inspect the response from any HTTP request using the DevTools Network tab. To make finding your Comet request easier, select the XHR filter button at the bottom of the Network tab panel. You may need to reload the page after opening the Network tab to refresh the list of requests. Sometime it is necessary to switch back and forth between the All and XHR filters to see new requests that have been initiated since selecting the XHR filter. Once you have identified the request item, click to select it. On the right panel choose
Response from the taps at the top
I'm getting a strange issue only Chrome + Firefox. It doesn't repro on IOS or IE9.
Here's the repro:
Load Home page http://example.com
Login (via a rel="external" hyperlink). In my case I use Facebook's Oauth Server Side flow - so this URL is a facebook.com.
Facebook accepts the user's credentials and then redirects to http://example.com/user/callback. Here various facebook data is processed (it is provided in the query string).
The server side code at http://example.com/user/callback then redirects the user to http://example.com. The mechanism used for the redirect is a RedirectToAction from ASP.NET MVC3. This returns a 302.
Expected Result:
User would see a URL in their browser = http://example.com and the content all nicely shown. This works on IE and Safari.
Action Result (on Chrome Only)
User gets a URL in their browser = http://example.com/#base_domain=example.com
The actual page is blank (no visible content)
However a view source reveals that the content is present.
Action Result (on Firefox Only)
User gets a URL in their browser = http://example.com/#_=_
The actual page is blank (no visible content)
However a view source reveals that the content is present.
Additional Info
If I enter the URL http://example.com/#base_domain=example.com into IE I get the same 'hidden' content (i.e. blank page with HTML source still present).
I should also note I use the RedirectToAction/302 redirect technique in other parts of the application with no issues whatsoever.
The issue also repros with AJAX navigation turned off.
EDIT: This also works on Safari (OSX + Windows) with no issues. It's only apparently broken on Chrome + Firefox on both Windows and PC.
IOS/Safari: OK
Win/Safari: OK
Win/IE: OK
Windows Phone Emulator: OK
Win/Firefox: borked
Win/Chrome: borked
OSX/Safari: OK
OSX/Firefox: borked
OSX/Chrome: borked
Not sure about Android.
The best solution appears to be setting the Push State and Hash Listening to false - so chrome/ff completely ignore them. I already had AJAX navigation disabled (there some interesting behaviours with it I hadn't completely accounted for yet with my server side code).
$.mobile.pushStateEnabled = false;
$.mobile.hashListeningEnabled = false;
I'll probably wait for 1.1 and stabilise the rest of my code before trying to get AJAX navigation working.
I've got a form in a web page with an action that is "mailto:email" (where email is a real email address). When I load this page in Mobile Safari in regular mode (ie, not launched from home screen with app-capable mode), this works fine - after I submit the form, the email app comes up. However, when I'm in app-capable mode and have launched from the home screen (so, no Safari chrome), and submit the form I get the error "URL can't be shown". However, a regular mailto: link (ie, not in a form) does work when in app-capable mode.
Has anyone else noticed this? Any workarounds? Are forms disallowed in app-capable mode?
Thanks,
Elisabeth
This accurately describes the issue. There is nothing wrong with the mailto link, the mailto link fails to load. Often the webapp crashes.
The funny thing is that tel: link for telephone numbers work fine.
window.location.replace does in-fact work. Thanks!
Here is the jQuery to fix this automatically...
$('a[href^=mailto]').click(function (event) {
event.preventDefault();
window.location.replace = $(this).attr('href');
return false;
});
I think I've figured this out. I noticed when in app-capable mode, any http link will take you out of the app and launch a separate mobile safari window, take you to the page and show the Safari chrome. Makes sense (typically one wouldn't link to anything from an "all in one" app-capable web app. I noticed this because I implemented a 4 page app with my own "tab bar" at the bottom and was linking amongst the .html files with plain http links in the a element. When I replace this with a javascript function to load the pages using document.location.replace this doesn't happen.
So, on the form - I think what must be happening is that because I'm using a scheme (in this case, mailto:) somehow the browser is needed in "regular mode" to interpret the scheme and do the right thing by launching the email app and this clearly doesn't work when submitting a form. I haven't yet found anything in the Apple documentation specifically about this, so if anyone knows the technical details, please do post!
UPDATE: I did find that I can access a server side script using a form in web-app mode, so I'm still curious about the mailto: issue, if anyone has an answer.
Thanks,
Elisabeth
I am having the exact same issue with mailto links not working in the web capable mode. I just got done submitting a bug report to Apple. Let's see what happens, meanwhile I found another dev. platform for web apps that works in web capable mode and mailto links work, but it is funny how it works in this even--it is not as fluid as it is in Safari. Because even in this new web dev tool that I found, it closes your app and launches mail client, which is lame. In Safari it just slides in a mail window that slides back out if you hit cancel or send--it doesn't actually close your app.
Here is a workaround that does not depend on JQuery:
aTmp = document.createElement("a");
aTmp.href="mailto:example#example.com?subject=Test&body=Hello.";
aTmp.click();
Update: To run this code from a bookmarklet you have to wait about 1000 ms before the bookmarks bezel is closed and the browser is ready to respond. I realized this by wrapping the code in a setTimeout function.