Facebook's mobile examples use the script: http://connect.facebook.net/en_US/all.js. This script adds to the div fb-root. My mobile site is 320px wide and I use the viewport meta setting. Including Facebook's script causes a big extra space on the right side of the actual content because it's settings it's contents to 575px wide. I tried including code to replace the 575px with 320px ("#fb-root").val().replace("575px","320px"); but that hasn't helped -- maybe I'm doing it wrong (using jQuery).
Anyone know how to restrict this to 320px?
Update:
Found a bug a report on this with two work-arounds:
Set status to false in the FB.init. I can verify that this does fix the problem for me, but breaks the ability for users to login.
Move <div id="fb-root"></div> directly under <body>. This didn't work for me.
Source:
http://bugs.developers.facebook.net/show_bug.cgi?id=18528
I used the following css style rule to beat this 575px #fb-root width problem:
#fb-root > div { left:-575px !important; }
That works because, if you locate the #fb-root node in, say, Firebug's HTML tree-viewer, you'll find that it contains a child div that is styled as follows:
position: absolute; top: -10000px; height: 0pt; width: 0pt;
i just set this in the css by default
#fb-root{display:none}
and when i need to use the FB dialogs(when calling FB.ui), i do this:
$('#fb-root').show();
and in the callback of the FB.ui, i do this
$('#fb-root').hide();
so here is an example:
var inviteFriend = function (msg) {
$('#fb-root').show();
FB.ui({
method: 'apprequests',
message: msg
}, function (response) {
$('#fb-root').hide();
console.log('sendRequest response: ', response);
});
},
this works for me, and i have tested on some devices.
The code you've provided seems to only replace the value in the code, which has, by that point, already fired. You might try to setting the width with jquery's .css() method on fb-root. Make sure this is fired after the fb js sdk is included, or put into the callback method if loading asynchronously.
Or just wrap it in another div, set its height and width, and the put overflow:hidden;
Related
I'm currently trying out Dygraphs (which seems really great btw!), but for some strange reason, the annotations feature won't work for me, AND it also fails in the exact same way on the jsFiddle version of Dygraphs' own gallery example of annotations, so this is most likely a bug/problem the devs really might want to take a look at(!).
To reproduce (same thing happens in both latest Firefox and latest Chrome):
1.
Look at the "annotations" example in the Dygraphs gallery, here:
http://dygraphs.com/gallery/#g/annotations
It works just fine and looks great, like this:
2.
Press the "Edit in jsFiddle" button, for that very example on that very page.
You are now sent to jsFiddle, and if you press the "Run" button there, the chart itself (colored curves etc) is shown just fine, but, only the "stems" of the annotation "signs" are shown, while the text contents of the annotations are all displayed as normal text to the left of the chart?! Like this:
Seems like some kind of CSS problem or similar to me, am I correct?
Since the example is Dygraphs' own example, which also works on their own site but not on jsFiddle, all suspicions of incorrectly formatted data or code can also be let go, I guess. It also happens to all my own Dygraphs charts on my own computer that I try to annotate, but this native Dygraphs gallery example is a much better example to investigate from I guess?
So, my question is of course, why does this happen, and how do I fix it to get the annotations working and displaying correctly?
ADDITION:
Let's make it even simpler, in order to isolate the problem without any hesitation.
Here is a very simple example for Dygraph annotations that I have put together on my own local disk (i.e. as a stand-alone HTML file):
<html>
<head>
<script type="text/javascript" src="dygraph.js"></script>
<link rel="stylesheet" src="dygraph.css" />
</head>
<body>
<div id="test_chart" style="width:750px; height:350px;"></div>
<script type="text/javascript">
var test_annotations = [
{
series: "TestCol1",
x: "2017-05-26",
shortText: "A",
text: "Test annotation",
cssClass: 'annotation'
}
];
testchart = new Dygraph(
document.getElementById('test_chart'),
"Date,TestCol1\n" +
"2017-05-25,110\n" +
"2017-05-26,80\n" +
"2017-05-27,75\n",
{}
);
testchart.setAnnotations(test_annotations);
</script>
</body>
</html>
When I open this file (locally with file:// in Chrome on my computer, having the latest dygraph.js and dygraph.css in the same directory), this is what I get:
As you can see, exactly the same problem as described above appears here, i.e. only the "stem" of the test annotation is visible in the graph itself, while the annotation text ("A") is displayed to the left of the graph.
The Firebug console is empty after having loaded this file, and no attempts (unsuccessful or otherwise) of loading any images are anywhere to be found in the Firebug network tab either.
Again, this very much feels like some kind of CSS positioning problem to me, but I may of course very well be wrong?
The answer to provide to this question would then be:
How, in as few and simple changes/steps as possible, would I get this local example PoC code for Dygraphs annotations to work as intended, i.e. showing the annotation text "A" inside a square at the correct position inside the graph (i.e. at the position where the "annotation stem" is currently just displayed, just as is done in the working example on the Dygraphs page, in my first screendump above in this question)?
Setting
position: absolute
solved the problem for me.
The gallery example loads images from dygraphs.com. When you load the demo on jsfiddle, it tries to load the images from jsfiddle, which doesn't work. dygraphs annotations are working fine, it's just that the image files are missing.
It seems that I was right about the CSS positioning problem after all.
The annotations are rendered by Dygraphs by adding the following HTML to the DOM of the page (this is the exact HTML for my test annotation in my local example code in the question test above, extracted live using Firebug):
<div style="font-size: 14px; left: 392.5px; top: 241.214px; width: 16px; height: 16px; color: rgb(0, 128, 128); border-color: rgb(0, 128, 128);" class="dygraph-annotation dygraphDefaultAnnotation dygraph-default-annotation annotation" title="Test annotation">A</div>
If I (as suggested by this SO question) add the CSS property position: relative to this div (manually, using Firebug), the graph suddenly looks like this:
See, the annotation text is now correctly positioned! It's still missing its opaque background and colored border though, but I guess this is just the result of even more CSS properties missing for some reason?
So, let's focus then on why there is missing CSS for the annotations I guess?
My best guess is that the dygraph.css file isn't properly loaded under certain conditions (apparently both on jsFiddle and locally on my computer, even though it is indeed there in the same directory as the HTML file and dygraph.js)? Or am I wrong?
A Firebug dump of the applied CSS for the annotation div seems to support this. Here is the CSS from Firebug for the annotation div of my local example (and also same in jsFiddle):
And here is the CSS for the same thing in the working instance in the gallery on the Dygraphs site:
See, the classes from dygraph.css is completely missing in my local example and in the jsFiddle example (even though indeed explicitly referenced in the class attribute of the annotation div's html code, as can be seen above), even though the CSS file is indeed there in the same directory as the dygraph.js file?!
#danvk, do you have any idea why this happens, and if Dygraphs could be patched somehow to avoid this from happening, and thus load all the CSS that it is supposed to for the annotations?
The only working hack-solution I can find for the moment is to dump the entire contents of dygraph.css inline in the <head> of the HTML file, as so:
<style>
/**
* Default styles for the dygraphs charting library.
*/
.dygraph-legend {
position: absolute;
font-size: 14px;
z-index: 10;
width: 250px; /* labelsDivWidth */
/*
dygraphs determines these based on the presence of chart labels.
It might make more sense to create a wrapper div around the chart proper.
top: 0px;
right: 2px;
*/
background: white;
line-height: normal;
text-align: left;
overflow: hidden;
}
...
/* For y2-axis label */
.dygraph-label-rotate-right {
text-align: center;
/* See http://caniuse.com/#feat=transforms2d */
transform: rotate(-90deg);
-webkit-transform: rotate(-90deg);
-moz-transform: rotate(-90deg);
-o-transform: rotate(-90deg);
-ms-transform: rotate(-90deg);
}
</style>
After that it's finally working fine:
Addition:
It seems like others too (1) (2) have this general problem regarding the loading of CSS files. No accepted answer to neither that SO question nor Mozilla support thread though, and indeed, none of the suggested answers work for me either. WTF, how can such a huge problem be generally unknown/unanswered? Please do also note that the same thing happens for me in both Chrome and Firefox, and also on multiple computers, out of which some have never opened the file before, so no strange cache-related effects should be involved either. Either way, it would seem like the bug is outside of Dygraphs' scope.
I'm afraid I'm late to the party, but it looks the problem is still valid (or workaround is not well documented). I was able to have better estimation of position by adding in index.html:
<style>
.dygraph-annotation {
position : relative;
display:inline-block;
}
</style>
However still annotations are not following the chart well:
The option attachAtBottom : true added to annotations might help here a bit, but still annotations are jumping on hovering graph (I guess this is because of legend taking some place)
All day trying to solve the same problem as the author at the beginning of this post. Yes, changing the CSN file allows you to somehow solve the problem, but everything worked by itself without dancing with a tambourine when I added this one line:
link rel = "stylesheet" href = "// cdnjs.cloudflare.com/ajax/libs/dygraph/2.1.0/dygraph.min.css" /
As always, you need to be more attentive to the little things)
Here is a fiddle (jsfiddle.net/salman/RQBra/show/) that demonstrates the problem I am facing. The iframes appear as expected in all browsers (including Safari 5 for Windows). But when I viewed the page on two iOS devices (iPad and iPhone) the content of iframe overflowed and covered the entire area on the right hand side of the iframe. Here is a screenshot of a page that uses similar iframes:
How can I workaround this issue?
You can fix it in a div, but on the iPhone it won't be scrollable without some javascript. I've made a fiddle that shows how you can fix the size of the iframe.
http://jsfiddle.net/RQBra/29/
basically, you wrap your iframe in a wrapper and give it some css:
#wrapper {
position:relative;
z-index:1;
width:400px;
height:400px;
overflow:scroll;
}
A workaround for your specific case is to replace the <iframe> by an <embed> element.
<embed src="..." type="text/html" width="400" height="400"></embed>
It will have the desired effect on Safari Mobile and clip the content to the specified width and height dimensions instead of auto-sizing it. Hoewever, embed is not specifically designed for HTML content and unwanted effects may result when dealing with scrolling, contentWindow and different environments (it is not necessarily rendered natively), so test the case before using it in production.
W3C:
The element represents an integration point for an external
(typically non-HTML) application or interactive content.
Hmm, try to wrap the iframes in divs, but not constraining the iframe's width and height by themselves.
I am guessing inside Iframe there is an HTML file, so in HTML wrap the content in wrapper div
#wrapper {
position: relative;
-webkit-tap-highlight-color: rgba(0,0,0,0);
}
it's size will be relative to html body, than the viewportSizes may be as you wish
the second row is handling flickering on Iframe click, happens in ios'...
I created a fanpage and integrated a app with width 520px. Everything works fine but the context is 5px to 10px shifts to the right and so on there is a scrollbar shown at the end of page. How can I solve this.
I know scrollbars can be hidden with overflow:hidden and inside tag <body scroll=no> but this doesn´t solve the shift to the right.
You can try using the FB.Canvas.setAutoGrow method :
Please read the Facebook JS SDK Documentation of the FB.Canvas.setAutoGrow method. In that link is an explanation on how to use facebooks auto size functions to fix these sorts of problems.
The problem seems to be that facebook fanpages tabs have a html - padding with 8px!!!! to solve this I set in css: <body style="position:relative;left:-8px;">
I'm using the following code for my like button
<fb:like id="facebook-like" href="http://mysite.com/index.php" layout="button_count" width="450" show_faces="false" font=""></fb:like>
Some users have experienced the like button not showing up. Noted in 3.6.17 but observed in other versions. I'm somewhat familier with the firefox iframe bug, but I was currious if anyone has any work arounds for the facebook like button.
Like buttons that are rendered with javascript (<div class="fb-like"/> and <fb:like/>) get height=0 if they are initially hidden (display:none).
To work around this, create the element with javascript after the container is displayed, and then run:
FB.XFBML.parse();
Example:
result.show();
var like_box = $(".fb-like-inactive", result);
like_box.removeClass("fb-like-inactive");
like_box.addClass("fb-like");
FB.XFBML.parse();
This CSS solved it for me
.fb-like span, .fb-like iframe { height:25px!important; width:150px!important}
This is still an issue, as can be seen here (also contains fix):
http://codepen.io/wiledal/pen/cGnyq
Firefox does not draw the Facebook-like if the div is hidden at the time of parsing. In the example above I delay the showing of a div after different times. You can see that a like-button shown after 500ms does not get rendered in Firefox.
I managed a work around which does not cut off the comment dialog after liking, simply by using min-height and min-width instead of set values that was previously proposed.
.fb-like span, .fb-like iframe {
min-width: 100px !important;
min-height: 20px !important;
}
I had the same problem on Firefox only (v.29.0.1) and it turned out to be AdBlock plus (v.2.6) blocking the Like and Share buttons from rendering.
Can you try calling the like button like so:
<div id="fb-root"></div><script src="http://connect.facebook.net/en_US/all.js#appId=195243810534550&xfbml=1"></script><fb:like href="http://mysite.com/index.php" send="false" width="450" show_faces="true" font=""></fb:like>
And let me know if you're still seeing issues.
Leaving an answer because I can't leave comments yet...
Oli's nice CSS hack looked like it worked initially:
.fb-like span, .fb-like iframe { height:25px!important; width:150px!important}
but it clipped the comment box that tried to pop up when we actually clicked the like button.
Per's delayed parse solution seems to do the job; here's a bit more detail. In our case we had the like button in a drop down menu, which looked like:
<ul>
<li class="control_menu">
<span>menu name</span>
<ul style="display: none;">
<li><div class="fb-like-inactive" data-href=...></li>
...
</ul>
</li>
...
</ul>
with code that shows the drop down ul when the user hovers over the control_menu element. We used this code to handle the delayed parsing:
$(document).ready(function() {
$('.fb-like-inactive').closest('.control_menu').hover(function() {
var inactive = $(this).find('.fb-like-inactive');
if (inactive.length && (typeof FB != 'undefined')) {
inactive.removeClass('fb-like-inactive').addClass('fb-like');
FB.XFBML.parse(this);
}
});
});
It finds the fb-like-inactive buttons, then looks up the tree to find the containing control_menu elements, then attaches an event to the control_menu elements to detect when the user hovers over them. When it detects a hover for a particular menu element, it looks for inactive like buttons within that element, marks them as normal fb-like, and then parses just the content of that element.
I hope this saves someone some time.
I just spent an hour on this and on a much more basic level, you need to know that the Facebook buttons will not render when testing your page locally.
It may seems obvious but it will only work when rendering from a webserver.
Per's solution is based on the XFBML version of the fb button and I wasn't sure how to do this with the "html5 version" or if it is really possible but I found a CSS/JS solution that doesn't clip content instead so here it is:
html
<button class="like-button">I like this stuff</button>
<!-- This is a hidden like-box -->
<div class="social-share aural">...stuff...</div>
CSS:
html body .aural {
position: absolute;
font-size: 0;
left: -9999px;
}
jQuery:
$('body').on("click", '.like-button', function(e) {
var $socialShare = $('.social-share');
$socialShare.css({'font-size':'1em'});
var sw = $socialShare.width();
$socialShare.animate({left: sw-80}, 400);
});
You may have to use !important rule (in both css and js) or nest the .aural class depending on the rest of your css. If it doesn't work I'd suggest trying to change the default layout so it doesn't override .aural or nest .aural and as a last resort use !important..
I had the same problem but the culprit was setting tracking protection in about:config to true.
This tip turned me on to the idea initially:
Lifehacker: Turn on Tracking Protection in Firefox to Make Pages Load 44% Faster
My solution is completely different to any of the above.
I have a character animation in my page, and one of the elements has the id="body" (which is perfectly reasonable) however this seemed to kill the FB script.
As soon as I renamed my id, the share started working again; I can only presume there was some kind of conflict, as id'ed elements can be referenced as global variables.
I found this out through the usual process of removing elements until things worked, so I'm fairly sure it was this.
I created a custom facebook landing page using the same template I have used 3 times before. The problem is, this time, ther vertical scrollbar won't go away. This is the resizing code I have been using:
<script type="text/javascript">// <![CDATA[
window.fbAsyncInit = function() { FB.Canvas.setSize({ width: 520, height: 1200});}
function sizeChangeCallback() { FB.Canvas.setSize({ width: 520, height: 1200});}
// ]]></script>
and at the bottom of the page:
<div id="fb-root"></div>
<script src="http://connect.facebook.net/en_US/all.js" type="text/javascript"></script>
<script type="text/javascript">// <![CDATA[
FB.init({
appId : 'MY_APP_ID',
status : true, // check login status
cookie : true, // enable cookies to allow the server to access the session
xfbml : true // parse XFBML
});
// ]]></script>
My CSS uses body {overflow: hidden;}, inside my app "auto resize" is selected. The issue is not that the ifarme won't resize (it does), it's that I have an empty vertical scrollbar on the right that won't go away.
Since the iframe design uses the whole 520px width, the empty vertical srollbar gives me the dreaded horizontal scrollbar. Judging by the width of the horizontal scrollbar, it's the vertical scrollbar causing it and not anything (that I can find or see) in the HTML/CSS making the page wider than 520px. The problem happens in IE8, IE7 and Firefox.
You can see the page here.
I have tried a few variations of the javascript code from a few different sources, but no luck. Not sure if this is something small I'm missing or if it's yet another facebook bug. This problem is not present on any of my other facebook iframe landing pages. After searching around for an answer and coming up with nothing, I've hit a wall with this one.
Its this code
html {
overflow-Y: scroll;
}
in your style.css style sheet thats causing the problem. When I inspect it with Chrome and remove that value, the scroll bars disappear.