Basically I want the iFrame that contains my app to expand and shrink as the content changes.
I know this question has been asked a million times but Facebook has changed their JS API a whole bunch and as a result the previous answers to this question no longer work.
I've tried FB.Canvas.setSize(); as other answers have suggested but to no avail. Does anyone know the method that actually works at this point in time?
My app can be found here for reference: http://www.facebook.com/SandboxAppPage/app_441443775903676
Edit: I can't even get a basic skeleton app to behave and resize properly. My basic HTML skeleton (no html, additional js libraries, images, etc) is still fixed at the default 800px height.
Have you tried FB.Canvas.setAutoGrow? It should fix your problem. This function works only when Canvas Height is set to Fixed at 800px in app settings.
FB.Canvas.setAutoGrow(1000);
Here the function will be called in interval of every 1000 milliseconds and resize the window based upon your contents.
Related
I'm building a website for a client who wants a horizontally scrolling site, that also accommodates vertical scrolling per "page" when the content won't fit. I did not know how to do this without help, so I started with Álvaro Trigo's Full Page js which you can see here:
http://www.alvarotrigo.com/fullPage/
And I hacked around until I got this:
http://www.valleycharacter.org/
This is working relatively well so far, except for one thing:
If the browser window is wide, but not very tall, so that the content is deeper than the height of the browser window will allow, there is no scrolling ability for the site. I've tried many different ways of enabling scrolling, but they either don't work at all, or they work for one page but not others, or only after re-sizing the window slightly to somehow "wake up" the scroll bar.
Is this even possible? I'm thinking that there might be some combination of the methods used in fullpage that create a situation where vertical scrolling isn't an option? I'm stuck.
You just need to debug the page to see that there is an error:
Uncaught TypeError: element.find(...).slimScroll is not a function
That could mean many things, but taking into account that you are using a jQuery plug-in, most likely it will be one of these two:
You are using an old version of the plug-in.
You forgot to include one library needed for the plug-in to work.
As you copied the code from Álvaro Trigo's example page (you should update the meta tag so your page description is accurate and it doesn't look like the page is owned/developed by another person), go there, and check the source code.
There you can see that he is actually including a library that you are not:
<script type="text/javascript" src="../vendors/jquery.slimscroll.min.js"></script>
Download that file, include it in your project, and then the error is gone, the page fits better within the screen, and the scrolling works fine now.
I'm working on a responsive website and I'm so frustrated with finding a solution for this one.
this is the basic structure:
I used 'vh' sizes and when ever the URL bar slides up - the page changes the sizes of the elements and kinda "jumps", which makes a bad user experience especially when reading.
I changed the size of the second part (orange) to 'em's because I thought maybe it will not "jump" so at least where there are texts this will not happen - and I was wrong. it's still happening.
What I'm trying to get to is to make the first part (in baby-blue) opened on all of the screen no matter what screen size is displaying the page (but without making it "jump").
I'm very frustrated finding a solution to responsive pages, can you please help me solve this, or help me with some reading material that will help me solve this ?
Note: I found some codes to add that should remove the URL bars from iPhones and it didn't work :I
Since you've tagged Javascript/jQuery I'd suggest assigning the height by getting the height the specific element (eg: window, document or viewport) you want. A good comparison can be found here. From the looks of it, you might want window.outerHeight which may account for what's "under" the URL bar. On my desktop, it's the only value that's different from the rest but on mobile other values may be different as well.
document.querySelectorAll(".whatever").style.height=window.outerHeight;
I've implemented the solution described in this previous post Resizing an iframe based on content and it's almost working great, but not quite.
The problem I'm getting is that sometimes it calculates the height correctly, sometimes it calculates it way too short and the content gets chopped off.
I'm looking for some suggestions as to what may cause this, because everyone else seems to have success. It seems to me that if the height is calculated incorrectly, then perhaps the calculation is happening before all the data has loaded into the iFrame from the external source. But that is a guess, and I am by no means a JS expert.
Is there something I can do to ensure that the calculation is done after the external page has finished loading?
It is pretty much impossible to get the height calculated right. I have played around with it for quite some time. One of the things I have experienced is, if you have a form inside the iframe and there are some error handling events in the form. Lets say there is a table in the form with hidden rows etc. Then when the errors appear the table gets "higher" as the rows start appearing, so the height range is now different again. Whenever there is a post back done inside the iframe one can not control the height. I have tried about every solution posted out there and could not get it calculated right. I had to estimate the "highest" height and hard code it to be that height.
I expect the issue is that you need to detect when the content in your iFrame is changing and then resize your iFrame again. In modern browsers you can use mutationObserver to do this, but it doesn't work in IE10 downwards, so you have to use failbacks to workaround this.
I wrote a small library that looks after all these issue and will keep an iFrame sized to it's content. Work's in modern browsers and IE8 upwards.
https://github.com/davidjbradshaw/iframe-resizer
In the project I currently work on we experience very strange rendering issue. The worst thing is that this issue emerges completely spontaneously and after several days of testing we haven't managed to find the sequence of actions wich would reproduce this issue. Here is an explanation of how this bug look like. Here is a screenshot of how the page should look like:
But instead of this after some manipulations content block pops up so only the part of the content is visible and its look like:
The most strange thing is that such a position of the block is not based on values of CSS properties as shown by Web Inspector.
As you can see the CSS properties are ok, while the position of the block is not. This fact suggest me that it could be some rendering bug of the WebKit engine
The project is built using Ext JS 3.4 and it is a classical one-page web application. This issue was seen in the last versions of Chrome and Safari on Mac OS 10.7/10.8. Though due to the spontaneous nature of this issue it might be present in other browsers and platforms too.
Any piece of advice on how to debug such issues or how it could arise is welcome.
Please check if any of your code or Ext JS's code is using scrollIntoView method, we have seen similar issue when scrollIntoView is called on any element that does not have overflow set to auto and it is inside an clipped element that is probably placed relatively positioned.
It seems bug in webkit because it scrolls clipped element which is not happening in other browsers.
I also see two elements in same hierarchy which has overflow set to auto. And scrollIntoView is scrolling wrong element.
Chrome and safari on Mac are having problems with scrolling. If the element has been scrolled and the content changes, the scroll position is kept even if the content is not high enough to require a scrolling.
The work around we have found in our application is to resize the container (the one that has the scroll) so that it has the scrollbar (or else you cannot play with the scrolling properties) and then reset the scrolling, and the height.
$(container).css('height',1).scrollTop('1').css('height','');
Here is how we do it in jQuery. You will not even see a flickering :)
I am not sure if it is the problem, but this thing kept us on our feet for a while.
i went through the same problem while working with a sencha touch 2 app and because thats same as ExtJS i have a solution for you
this probably is a bug in the framework and this happens when the ExtJS renders the application before the browser populates mayb the correct window.innerWidth and window.innerHeight and thus the viewport cannot take the correct width and height. this also explains the randomness of the event. This becomes more prominent when used on mobiles probably because of the limited resources and slow response.
the solution that i took to handle this mayb isnt a good one but i couldnt find a better one considering is a glitch in the framework itself
i poll for the correct height and width of the browser for around a sec after every say 100ms for the correct height and width of the window and if i find that the height OR width of the viewport isnt same i re adjust it. because you are working with ExtJS and app would run on high powered systems(as compared to mobile phones) i would recommend a smaller interval and then to be safe a larger time period to which it polls.
heres the code that i use currently edit according to your needs
var aId = setInterval(function () {
if (Ext.Viewport.getWidth() !== window.innerWidth || Ext.Viewport.getHeight() !== window.innerHeight) {
Ext.Viewport.setSize(window.innerWidth, window.innerHeight);
clearInterval(aId);
}
num = num + 1;
if (num > 10) {
clearInterval(aId);
}
}, 100)
i currently use this code inside the launch function of the app. but you can also use this inside the show event of the viewport for which you should keep the interval time to minimum possible to avoid any lags.
with this if you think this app might be used on devices where the window height and width would be changed by the user (like that of mobile browser when the orientation changes or if you think user would change the height and width of the browser window). then just copy & paste the same code piece inside the viewports resize event so that it also polls and resizes viewport when the size of the viewport changes.
Did you try adding a clear:both; block after the toolbar div ?
<div style="clear:both;"></div>
#bjornd it's pretty hard to debug without any code :)
Is the toolbar positioned and has the content an ID that's called in the URL?
In other words: is there some link (e.g.) that triggers #content and has no preventDefault() etc? This would scroll the page probably.
I dunno, this was the first thing that came to mind.
It could also be the toolbar content that is (for some reason) no longer cleared or some change in the content's top position (relative to another changed/removed element?)
Try and create a stripped-down test-case that contains the simplest of code but still triggers the bug. If you post that (through e.g. a Fiddle etc) we can have a proper look.
It might be a css issue;
I've had a similar issue using equal height divs by setting a padding-bottom: 99999px; and margin-bottom: -99999px;. Which workes fine in all cases, except when you use hashtag anchors to jump to a div further on the page. Jump down.
In that case the top of the page clipped and started with the div I wanted to see.
Since you say the problem is pretty hard to track, this might be something to have a look at. The solution was to remove these 2 css lines and use another method of setting div heights.
Has anyone built anything using the new "fluid canvas"?
Besides the sample code not working in IE 8, are there any other problems with doing this?
I'm wondering if I would be nuts to build an application using this? I mean, what would I do, check the available width of the screen and do different things for every user?
Isn't this prone to error? Any thoughts?
Thanks!
even for "fluid" canvas, it is very likely that we are not going to check the available width of the screen (as the screen/browser window can be resize dynamically by the user).
instead, as it is an iframe, it is exactly the same way how we should built the canvas / web page that meet our needs or show best to the user by making use of the full width of the browser window.