We Keep Coding

Facebook 'Like' Dialog Appears and Immediately Disappears

I've been having an issue with the Facebook Like button for quite some time. I've looked all over for a solution but am quite stuck. The error occurs on my site www.MapYourVote.com. When you go to a poll page and click 'Like' the dialog appears and quickly disappears. At the same time, the counter also goes to 1 and quickly goes back to 0.
The problem is always solved for individual poll pages by using the Facebook Debug tool (http://developers.facebook.com/tools/debug). Once you use it on the url, the like button will work as expected. The issue is my website is dynamic and I can't use the Facebook Debug tool every time someone creates a new poll. The Facebook Debug tool does not reveal any problems (apart from og image size but I doubt that's the issue).
Here is an example of a page in which the Like button does not work. If you were to enter this url into the Facebook Debug tool, the Like button would work.
http://www.mapyourvote.com/Poll/Election-Result-Feelings/
Any help would be much appreciated!

I also had this problem. I was constructing a referrer url to give link-sharers a credit, so there was a different url for each user that wanted to share something. The referrer link would give the user credit and redirect to the login page of my site. With this configuration, the like dialog would appear for a moment and then disappear again, unless I went to facebook's debug tool.
What fixed the problem for me was to change from a redirect to rendering the page directly from my referral link. In fact, I changed the referral link to be a ?r=refid parameter on my root page URL. It appears to work correctly if facebook doesn't have to follow a redirect to get the og: data.

I had a similar problem and it turned out I had too restrictive cookie policy set in my browser - I only allowed Facebook to use 1st party cookies. When I allowed Facebook to use other cookies, the problem was solved. It's hard to debug when no error appears other than the immediate pop-up closeup.

I had the same problem. It was caused by url value in data-href attribute. I had there url pointing to my localhost.
When I changed the url to existing one, problem was solved.
Hope it helps

For me, the problem (Like popup disappearing after a second) was happening when the Like button URL redirected to another URL.
The fix was to add og:type, og:url, and og:title (required per https://developers.facebook.com/docs/reference/opengraph/object-type/website), then running the URL through the Facebook debugger to clear the cache (https://developers.facebook.com/tools/debug).
More at https://stackoverflow.com/a/16597060/2391566

How do Optimizely trick chrome to no prompt for loading insecure content

In one of the latest chrome updates , the chrome team added the "load anyway" message that prompts a user to approve loading insecure content on secure pages , somehow optimizely have found a way to "trick" chrome not to ask for that question and simply load the content with the yellow warning key , e.g. : https://www.optimizely.com/edit#url=http://www.yahoo.com/
I can't seem to understand how they did it... does anyone understand ?
Thanks

It looks like they do it after page load. The initial page served only includes an innocuous <iframe></iframe> - no insecure content loaded yet. Javascript does the actual loading of the iframe.
I did some testing and I can't get any message to appear on Chromium 18 (Linux). However, on my test page, the security icon starts green on page load, then turns yellow when the insecure content is loaded to the iframe. The exact same happens on Optimizely. So my best guess is that this method will avoid the "Load Anyway" message while letting you load insecure content.
Don't count on that though - if this is a new Chrome feature, it's likely they'll figure out this trick as well and fix it later. ;)

They don't seem to get around it on Chrome:
They ask the user to enable it as per this screenshot:

Facebook FB.login() Popup Won't Close in IE8

I've searched for answers to this -- seems like all the answers relate to the old Facebook API so the solutions are no longer relevant.
The problem I'm having: I've got a custom Facebook tab which has a button on it that, when clicked, triggers FB.login(). The way it should work is: user clicks to log in, popup comes up to authorize the app, user clicks authorize, the popup closes. This flow works correctly on all browsers except IE8 and below. On IE8, the user clicks to log in, the popup comes up to authorize the app, the user clicks authorize, then the content INSIDE the popup refreshes with the content from the redirect URL. Needless to say, this is not the desired experience for IE8 users :(
I've tried everything I could find: doublechecked that there are no javascript errors, ensured that there is a valid channel file, etc. Nothing appears to fix it. Everything is happening through secure (https), so I'm not sure if that has anything to do with it.
I've been trying to fix this for DAYS now; any help would be GREATLY appreciated!

Make sure fb-root element is only once in your page , I have faced this issues and when i made sure that fb-root div is only once the issue got resolved

You should specify a p3p header in all responses from your web server. Please see: http://www.hanselman.com/blog/TheImportanceOfP3PAndACompactPrivacyPolicy.aspx.

By "the content INSIDE the popup refreshes with the content from the redirect URL" do you mean that you are passing a redirect URL? If so, don't do that. The popups work using some cross-domain JavaScript magic with a specially constructed redirect URL. If you put your own, then the popups may break.
Also, make sure you're setting a proper channelUrl when you call FB.init().

profiler for showing render statistics for web page?

I'm using a contrib drupal module that hooks into a form. Its presence appears to cause the jquery to render unreasonably slowly, but I'm not entirely sure about that.. I want to do some advanced troubleshooting on it, and I'm looking for a tool like xdebug that will give me an output file that I can view with KCacheGrind.
I've looked at Venkman and Firebug, but I don't want a debugging environment; I'm not at that point yet. I want to see a profile of the page load so I can see where the majority of the time was spent so I can identify where the problem is.
Edit: I'm actually not looking for a profile of the page load, as several folks have pointed out, but actually a profile of the javascript executed on a particular event. Firebug's debugger can grab the execution and step me into the code, but it just puts me at one point in the big ol' script. I think the slowdown involves loops and iterations, so I want to see a profile of the execution path.
Actually I think I should post this as a separate question.

In Firebug, click the "Net" tab. It lists every element it requests from the server, and detailed connection and load information (on hover) with a nice graphic display without hover.
Update
In addition, if actual page load isn't the issue, and you are indeed trying to profile Javascript, the Firebug "Console" tab probably has what you need.
Click "Profile" and then reload the page. Click "Profile" again to see a list of everything the javascript did with duration and timing information. This should show you what is taking the longest.

The chrome developer tools has a javascript profiler, that will profile all of the function calls on your page. The timeline feature (might only be in beta/dev versions) will show how much time the browser spends on various operations (layout and rendering for example) operations.
I believe that firebug also has a JS profiler.

There is a profiler in firebug in the console tab. Click once to start and second to stop the profiler. Chrome has also a profiler press ⌘⌥j. There is also a good profiling tool for internet explorer: dynaTrace ajax editon.
Btw. most of the time jquery is slow depends on wrong use of the selector engine.

Document.domain and <iframe>s breaks the "Back" button in Internet Explorer

This is a very urgent problem and I'd be forever indebted to anyone who can lend some insight.
I'm going to be deploying a widget (called the "ISM") to a third-party site. That site uses the document.domain JavaScript property to relax cross-domain restrictions (e.g., setting document.domain in "a.example.com" and "b.example.com" to both "example.com" so they can access each other's DOMs).
This causes problems with my script in Internet Explorer due to the way that I construct an <iframe> that is used to display my widget's HTML content. In Internet Explorer, using document.domain on a page, and then creating an <iframe> with JavaScript, will cause you to be immediately "locked out" of the <iframe> - i.e., you can create it, but it's not created in the correct document.domain, so you're not able to access its DOM due to security restrictions. This isn't a problem in any other browser.
To see what I'm talking about, load this page in IE:
http://troy.onespot.com/static/3263/stage1.html
You should see a JavaScript error: "Access is denied."
To get around this, I'm setting the dynamically created <iframe>'s "src" attribute to load a static HTML file that's hosted in the same domain (different subdomain), and setting its document.domain property to the appropriate value:
http://troy.onespot.com/static/3263/stage2.html
That gets around the security issue, and lets me write the document I originally wanted to write to the <iframe>:
http://troy.onespot.com/static/3263/stage3.html
With that document in place, my widget does some polling to our server to get some HTML content that I want to insert into another <iframe>, which will be visible to visitors of the parent page. I've roughly simulated that here (using static content, not actually contacting our server):
http://troy.onespot.com/static/3263/stage4.html
Here comes the problem. When I get that HTML content and insert it into the second <iframe>, I now face an unusual issue with a broken "Back" button. This happens in Firefox 3.0 and all version of IE (possibly other browsers), though it does not happen in some browsers I've tested (Firefox 3.5, Safari, Chrome). See this page:
http://troy.onespot.com/static/3263/stage5.html
If you click the "Google" link, all seems fine. But, when navigating back to the previous page (that has the latter test script), another JavaScript error is introduced: "Permission denied." This does not terminate the script, and does not appear to have any ill effects, other than the fact that I assume it's connected to the broken "Back" button functionality, which is a very big problem - the one I'm desperately trying to solve. I'm at a loss to debug this error since its call stack starts and stops in the jQuery script.
You can also encounter this error - with more serious symptoms - by going to the last link above (stage5.html - clear your browser cache first). Click the "Stage 5 (Again)" link, then, after that page has loaded, click the "Back" button.
The "Back" button is completely broken! You can't go anywhere except to another URL.
This is the problem that I need to solve as soon as possible. Any insights or help would be extremely appreciated!
I can't deviate from this method too much, so outside-the-box suggestions are definitely welcome, but I may not be able to use them due to the constraints of the widget's specifications. I would prefer to understand why the "Back" button is breaking and how to fix it, along with the "Permission denied" error related to jQuery.

It's really hard to try out fixes for this because of the multiple domains. One thing I've heard is that IE treats a blank src or "about:blank" as a different domain, but it treats 'javascript:""' as the same domain. Have you experimented with changing stage one to set the iframe src to things like:
iframe.src = 'javascript:""'
Or:
iframe.src = 'javascript:parent.getFrameHTML()'

Part of the problem seems to be that IE (at least IE 7) adds two entries to the history named "Domain" when I click on the "Stage 5 Again" link. When you use the little drop-down arrow next to the Back button you'll see the history of pages allowing you to step back more than one step. I see the previous two entries are listed as "Domain" and clicking either of those brings me to the same page. The fourth spot (after Current Page, Domain, Domain) is the correct "ISM Back Button" link to the original stage5.html page.
So the problem isn't exactly that the back button doesn't work, but just that the entries in the history are added and so the back button takes you to the wrong place. I don't have an answer as to why those "Domain" entries are being added to the history, but hopefully this helps point you in a useful direction.
Good luck!