Dear FB Developer Team,
we have an issue with the FB.Canvas.setAutoResize() function of the app iframe.
The frame extends vertically to the height of the first request, but on subsequent requests to pages with a lower height, the iframe doesn't resize vertically.
While we tried the FB.Canvas.setAutoResize() function, it seems not to work.
Could we somehow solve this issue?
Would be great to receive an answer here.
Best,
Max
This is a known Facebook issue, they're renaming setAutoResize to setAutoGrow for exactly this reason.
When your page shrinks in size you should use FB.Canvas.setSize to lower the height https://developers.facebook.com/docs/reference/javascript/FB.Canvas.setSize/
There have been several bugs reported about how
FB.Canvas.setAutoResize doesn’t set the height of the iframe correctly
in some scenarios. We have been trying to fix this and and have pushed
various fixes to ensure that it works correctly for the case when the
iframe grows in height. We however came to the conclusion that it is
hard for us to do this accurately when the iframe shrinks in height.
As a result we are renaming this function to FB.Canvas.setAutoGrow so
that it accurately reflects its functionality. If your iframe is
shrinking for whatever reason we recommend that you use
FB.Canvas.setSize with a height parameter to set the iframe height
explicitly.
As part of this change, you should be able to use
FB.Canvas.setAutoGrow today. FB.Canvas.setAutoResize will work for the
next 90 days and we will remove support for this method on January
1st, 2012. Here is some sample code to test the grow functionality.
https://developers.facebook.com/blog/post/565/
Related
Here is the desired outcome I'm looking to achieve by scrolling using react-scroll-parallax.
On Mobile browser
View web browser example here
Description
I want to create a website with the parallax affect shown above. The key elements being a website build in react containing three pages.
While scrolling from Page 1 to Page 2 I want the mobile device mock to start halfway on the screen (as to avoid the other content of page 1), then move to being basically centered.
While scrolling from Page 2 to Page 3, the website and components stick and once again act like a normal website scroll.
Additionally, during the scroll from Page 1 to Page 2, I want the content inside the device mock to scroll as well.
What I tried
For starters I was able to get nearly the affect I wanted by using a div with it's z-index and absolute position set, and parallax on translateY of -50, 125.
<div className={"absolute z-10 w-full"}>
<Parallax translateY={[-50, 125]}></Parallax>
</div>
The problem became however when I wanted to place content inside the div. Having another div within the parallax that also had z-index set seemed to mess with the parallax affect.
Important notes
Content inside device mock
One issue I found that was tricky was trying to place the content inside the device mock. I want a parallax both on the device mock itself, and the content within it.
I'm not entirely sure how I should crop the content inside the device mock.
The device mock svg frame and device mock mask can be found here if you want to give it a try
Device mock svg and mask
I tried imgs with various z-indexes, masking the div with an svg mask, using image backgrounds. Nothing is quite getting the preferred outcome.
Scaling of device mock
I want to make sure this works well on both mobile and browser. With that said I was trying to use margins to scale the device mock but I had a hard time with trying to then correctly get the mask to work for the content within the mock.
I'm not sure if using dedicated width and height sizes would be the ideal way to go, but very open to suggestions! It seems hard to scale the device frame and the mask properly.
Parallax of device and parallax of device content
I want the content inside the device mock to be html so that I can change it more than just an image. That being said the most important feature I want is for both the device and the content inside to have a parallax scroll affect.
Summary
I know this is a bit much for a quick simple stack overflow issue, but I've been trying a lot to get this to work and just can't seem to nail down the little details correctly. I sincerely appreciate all help and suggestions and if there is anything else I can provide please let me know!
The trickier part of the request was blowing up the <svg>, adding new <path /> and <clipPath /> for the color swap inside the phone mock.
Eventually I got it working here. The part linking the clipPath transition to the scroll progress looks like this:
const [y, setY] = React.useState(1739);
const onProgressChange = React.useCallback(
(a) =>
setY(Math.max(Math.min(1739, 1739 - ((a - 0.24) / 0.0018) * 17), 36)),
[setY]
);
const { ref } = useParallax({
translateY: [0, 185],
onProgressChange
});
The 1739 and 36 are max and min values for the translation and they are strictly related to the svg's viewBox. The other values allow tweaking the start, end and speed of animation, with regards to overall scroll progress.
This, together with some CSS, took care of binding the right animations to the correct scroll progress.
Feel free to tweak it some more, especially if you add more markup.
The other thing I wanted was a function activated shortly after scrolling, which would snap the scroll to certain positions. Namely, to the .page elements.
I used gsap's ScrollTrigger plugin for the task, for multiple reasons:
I'm somewhat familiar with it (used it before)
it's performant, light and non-obtrusive (basically quits when it detects another user scroll)
listens to all relevant events (touch, mouse pointer, keyboard) without me having to make sense of them, providing a unified interface.
uses inertia (if you scroll down faster from page 1 it will scroll past page 2, directly to page 3 - other scroll plugins limit you to having to scroll once for each page change)
works well on mobile devices
There are other libs/plugins out there for the task, you don't have to use gsap (although I do think it's awesome). If you end up including it in your project, make sure you comply with their licensing (which is not MIT).
By the way, my first choice for the parallax effect per-se would also be gsap, as their timelines provide a lot of flexibility and options.
Their most advanced stuff is reserved for subscribers, but even if you limit yourself to the free plugins, you're still getting more than from alternative libs/plugins, IMHO.
See it working.
In IOS7 (Safari) we are seeing an issue where the iframe will not accept a lower width/height. For example, on an orientation change event the new width maybe say 600 vs 320. While it will resize to 600, going back to portrait mode, the width will remain at 600 instead of resetting back to 320. We have confirmed the values are being set correctly within the attributes of the iframe, but the css values are remaining at the previous larger values. We've tried clearing the style attribute altogether, resetting the dimensions to 0 directly before setting the new values, etc. Nothing seems to take affect. I'm leaning toward believing this is a safari bug. Has anyone else experienced this? All of the other posts that are similar all seem to be reporting scrolling issues and not resizing issues.
IOS will show all visible content, so you can't hide the overflow of an iframe. Is your content wider than the iframe? I have a feeling it might be
Has anyone ever seen this before, Chrome is calculating my values, even in the body too specifically. Meaning the values are in the millionths if not billions decimals places:
Example:
width: 281.6477355957031px;
I do not have this problem with IE. I normally wouldn't care, but these fractional pixels are really screwing up an effort to add a sticky header to a common grid control we've developed to work with OData.
This issues seems to happen when just a body tag is on the form with no other lower level controls. I am baffled.
Does anyone know of a way to reset the entire html page or even better, just reset a particular element so that every element beneath it calculates using whole or near whole values?
thanks!
EDIT
Just to be clear, I have taken everything off the page except the main container, with no styles and Chrome is calculating this parent html tag, with a value of 1508.1817626953125px. This element has no styles attached
To answer my open question, the cause is Visual Studio 2012. Since I was using localhost to run my site, some plug-in or setting is set to force chrome that specifies dimensions much more specific than any normal human would want. Upon not using machine name instead of localhost the dimensions are back to normal. If i find the exact setting, i will report back later.
EDIT:
Upon further discovery, its not VS, its my browser zooming. At certain zooming in Chrome pixels in the development console are calculated to a sub pixel level. I imagine due to some inner division calculation. This throws off my calculations for allowing the a staic table header at different zoom levels. I will be forced to deal with CSS pixel rounding in my own calculation to handle these.
I can't seem to find an answer to this rather interesting problem. In google chrome, images that have a set width and/or height, either using attributes, inline styling or css styling, refuse to show up on the page on initial load. They only seem to appear after there has been some page activity. Yet, if you let the images load to their natural size they display on page load perfectly fine. The images can be seen as it works in other browsers and when inspecting elements in chrome the image is display in the popup window.
Any know how to fix this?
define what you mean by: 'after some page activity'.
You also mentioned that the it happens when you have set width AND/OR height which leads me to believe in some of your testing your ommiting width OR height so it can be calculated by the browser. if that is the case then yes the image will never look proper and the elements will have no size on initial page load UNTIL the image is downloaded, the browser inspects the image and determines the dimensions missing to create the bounding box.
Edit:
After looking at your online site, my previous comment explains the gist of it but I can see that you're setting a width of 'auto' which requires the browser to load the image first and detect the sizes. Which will cause a delayed 'reflow' in the browser rendering. Set your widths and heights otherwise they will need to calculated by the client browser. And if you have not so good pc it looks sluggish. On my system if i hard refresh with no cache sometimes i get all the thumbs and other times I don't and the delay is very noticeable.
So in short make your images always have a width AND height.
Edit:
You also have some 404 errors that can cause some latency. http://www.webpagetest.org/result/120725_0C_3N6/1/details/
Edit:
I think your only option is to load the bg image first by getting it higher up in the order of resources downloaded so it loads in as fast as possible to be rendered.
One trick might be to load the bg image in a hidden div to preload it right away so the browser downloads it first. And even if you do that you should expect to see some flash of black background while you wait for the high res shot to download and get loaded. Can't set widths and heights on background images anyways. Going further you can speed up the response time maybe by loading all the thumbnails with an AJAX call AFTER page loads so they don't even compete with the big photo shot and start downloading until the dom is fully loaded. You can even put a nice effect in there to maybe fade in the thumbnails loading or something to that effect.
The w3c specification says that the width and height are implied and not required. I have always been told that you're supposed to put it in anyway. If I remember correctly his reason was that the browser may not correctly detect the image size. Is this true?
It harkens back to the dark days of Netscape in the v4 and older versions. The rendering engines were primitive and wouldn't "reflow" content as they built pages and figured out sizes. If you didn't specify an image size, the whole page's rendering would get paused (or a full-page refresh would get pulled) once the image was downloaded and parsed for height/width. This looked bad from a user perspective, so the rule was to ALWAYS specify a size.
Nowadays, engines are better, and can handle an unspecified image size gracefully. Reflowing content is still a somewhat expensive operation, but does look cool from a user perspective as things glide/flow around as images pop in and text shifts to accomodate them.
The reason is that if you do not put them in, the browser will put a default size in, download the image, find the actual size then have to re-flow everything around the new size.
Re-flows are expensive operations - the rendering on screen has to be updated for each such image.
If you provide the size, the browser puts in a placeholder with the correct size and doesn't have to re-flow once the image downloads.
In my experience, not supplying width and height tags will cause the browser to render the image at its original size.
I've found this behaviour to be consistent in modern browsers.
As an aside, I always try to supply images at the size I want them rendered at in order to reduce the amount of bandwidth used and to ensure image quality.
I'm not sure about browsers not detecting it correctly, I've never seen that happen.
But to answer your question, I think the answer depends more on what you are trying to do, and possibly likely to do, which makes the difference.
For example, if the image you are adding is a banner ad which needs to conform to predetermined height/width, then by all means, hard code the height and width.
But if the image is something that might change over time, I would suggest NOT coding the height and width, as more than likely this means that the new image, if not the same exact height/width as the old one, will now be distorted. This is especially true on a dynamic website where images change all the time.