Kendo UI flip effect in Internet Explorer shows back too soon - javascript

I'm developing a BI dashboard for a business app using the JavaScript Kendo UI version v2014.1.416, but I'm having a problem with some visuals in IE11.
I want to point out that due to real-world constraints, running IE11 is for all intents and purposes set in stone. The Kendo version number is somewhat easier to deal with, but still no picnic.
Specifically, I use the kendo.fx.flip() function to display a flip card. The card flips ok, but the "back of the card" is rendered before the flip animation starts. In contrast, the same effect in Chrome and Firefox plays out as it should, i.e., the back is shown halfway(-ish) through the animation.
I had a look at the API reference page for the flip effect, at http://docs.telerik.com/kendo-ui/api/javascript/effects/flip. As it turns out, the reference page example exhibits the same behavior in IE11.
I'm guessing the effect uses the CSS3 flip function under the hood (haven't looked yet though) and this seems to be somewhat of a general problem given the amount of questions regarding flip in IE.
My question is twofold:
1) Is there a way to "fix" the animation specifically for IE, using the provided version of Kendo and/or using regular CSS?
2) Is this effect fixed for IE in later Kendo versions, in spite of the behavior on the API reference page?

I could only get this to look nice by setting a large no-repeat fixed background image on both 'sides' (made out of a simple white png).

Related

Why does UI "jump" on react-aria Calendar range selection within a radix Dialog?

I built a calendar component using Adobe's #react-aria & #react-stately hooks that I want to use within a Dialog on mobile (which is built using #radix-ui/react-dialog). The problem is that whenever the user selects a range, the whole dialog "jumps" a bit, almost like it zooms in, which causes part of the content to go off-screen to the right (despite having fixed positioning with right: 0 property). This is reproducible both in Chrome Device Mode (under 450px in width) and when testing on actual phones (in Chrome but not in Safari). This is how it looks:
After scouring the internet for a solution, I cannot figure out what's causing this. I found no styling that could affect this or code that could be the problem. The only thing I found that fixes it completely is adding the user-scalable="no" parameter to the content of the <meta name="viewport"> and I don't want to do this because of accessibility. My best guess after looking at the source code of both libraries is that it has something to do with both of them doing a lot of stuff under the hood to keep things like focus in check but I'm stuck.
Here's a codesandbox sample of my setup, where the issue can be observed (the app needs to be opened in a new window and then put into Chrome Device Mode to reproduce it!).
Any hints that might help me track down the issue are appreciated.

Phonegap native iOS7 blur effect

Is there a more native solution using Phonegap to create the iOS7 blur effect other than using CSS or javascript?
I have never used Phonegap before, my app needs the blur effect and I'm trying to decide to either use my web skills to create this app or hire a native developer.
Thanks guys!
The answer is, as usual, it depends.
CSS3 does support blur, but not in the same way iOS 7 uses. This means it is possible to create a static blur (say, on the navigation bar), but there is no great way discovered (last I knew) to enable a dynamic blur -- which is probably what you want, if trying to mimic iOS 7.
Although it flies a bit in the face of the question to pose this as a solution, one option is to simply not implement a blur. You can approximate something similar by using a gradient (say, 75% opaque to 100% opaque). Depending on your needs, this may be sufficient. (I first noticed this at this site: https://mir.aculo.us/2013/09/16/how-to-create-a-web-app-that-looks-like-a-ios7-native-app-part-1/)
The other option is to use a native navigation bar. It introduces its own set of problems (for example: how best to synchronize your non-native view transitions with native navigation bar's transitions), but it means you also get iOS 7's blurring on the navigation bar for free. I've got a (very alpha) plugin that implements this (as well as toolbars) here: http://plugins.cordova.io/#/package/com.photokandy.nativecontrols

Stuttery performance issues with Jquery Mobile and Phonegap

So, I am developing an app using phonegap and jqm. Everything works great and it's all pretty easy thanks to phonegap build. However, I've started to see some 'stutter issues' that are really annoying. My app at the moment only has two pages and the transition effect between them is 'slide'. The first page has a background color set to it and the second one does not. Some of the issues:
When I navigate from page 1 to page 2, half of the page has the background color from the previous page. It goes away after I do some random swipes on screen.
On one of the pages, I have a regular form with some text input fields and a radio button set at the end. When I move from an input box to the radio button the keyboard slides down but it is replaced by a black area for a short period of time.
The fixed header that I have at the top randomly decides to disappear and reappear again.
These are only few of the annoying ones and these only happen on the mobile device and it works fine on the computer. So, I know it's a performance issue.
I've read up about this on the internet and here on SO and different solution have been proposed like writing custom CSS3 transitions (to take advantage of hardware acceleration) or using something like zepto.js.
What in your opinion would be the best 'cross device compatible' method to overcome these? Is there a way to force hardware acceleration with jquery mobile? Is CSS3 performance even across device platforms?
PS. I have been testing on jelly bean 4.2.2. I am not posting any of my code because they are just plain form elements and some input tags and this happens on multiple pages which are totally different so I am pretty sure this isn't code related.
Any help will be much appreciated.
JQuery writes animations using Javascript which dynamically writes inline styles that change quickly. The issue with that, is that it isn't using the hardware acceleration and if you are testing on a retina device, it animates using pixels as they are a unit of measurement. So it is skipping half of your pixels which causes the stutter.
I have written apps using PhoneGap and the best way I came up was to use CSS3 animations/transitions. Super smooth and they feel just like a native app. You will still use JQuery to add/remove classes, etc., but the movement should come from your CSS.

Rendering bug in Google Chrome at certain window widths

My users and I are running into a rendering glitch in Chrome only (on both Windows and Mac) where an overlaid div that I'm using for on-hover tooltip-style "popouts"(see first image below) does not get rendered properly in certain cases (see second image below). In all other browsers I've tested, it works as expected.
Here's how the hover popouts are supposed to look (and what happens in Firefox, Safari, IE):
Here's what happens in Chrome:
You can see it in action on this site if you look at May 24 using a browser window width of ~ 1200px (significnatly wider or narrower windows do not seem to work). The glitch only affects the popouts in the bottom right of the menu that are popping left, e.g. those on May 24. Hovers using the same exact mechanism higher up in the page work just fine. Glitched popouts are invisible (except for part of the carat), but if you click on the link to lock the popout in place and then hold left click while moving your mouse around as if to "select text" in the area where the popout should be, it will then render partially. Also if I open dev tools and try to select the popout, it will render just fine at that point.
I've been looking at this all day and trying different work arounds with opacity, z-index, etc. and getting nowhere. Does this glitch ring any bells for anyone? Is there a way to force Chrome to render the div, once its been positioned and unhidden? I'm fine with any work-around or hack.
I use a custom (and fairly complicated) jquery plugin for popouts. If it would be helpful to see the non-minified javascript for the plugin, I can post or provide a link to that, but general guidance that leads me to a work around will be sufficient to be accepted as an answer.
Edit: My Browser Build: 26.0.1410.65
(Per my comments)
This does indeed seem to be a bug in Chrome, though without a smaller test case to reproduce it, it could be very hard to track down. You may want to report it to the Chrome team with as much information as possible.
In support of my "it's a bug" assertion:
The hidden/clipped elements become visible when they are selected.
The elements underneath the hidden/clipped elements are not clickable.
This indicates that z-index and height is correct.
It only happens under very specific circumstances; the rest of the items with the same style work fine. The same item may work fine at a slightly bigger/smaller screen width.
Applying a 3D transform fixes it.
The problem goes away when I apply a CSS transform such as scale3d or translate3d. I imagine this is because certain CSS properties cause the browser to switch to GPU acceleration.
In this case, switching to the fast path for rendering seems to alter the drawing sequence enough to fix the problem.
Super hacky but this fixes it for me:
$('.drop-link.food').on('hover',function() {
$('.tool-tip').css('overflow', 'hidden').height();
$('.tool-tip').css('overflow', 'auto');
});
Obviously this isn't a "good" solution, and even remaining hacky you could probably optimize it to only force the redraw on the tooltip it needs to, but hopefully it helps...
Another clue:
$('.drop-link').on('hover',function() {
$(this).siblings('.tool-tip').css('display','block');
});
This won't fix it right away, but it seems like if this is there, once you've hovered on something, it will work the next time you hover on it.
Not sure if this helps with your situation, but over the last couple of days I've started to notice that certain site elements on Facebook and Weight Watchers no longer show up. Specifically it seems to be affecting items that (I believe) to be controlled by or dependent on Javascript. When I call up these sites in Firefox and Safari they work as expected.

IE7 CPU spikes, script problems & debugging?

A website I'm currently designing displays and works perfectly in all mac browsers, and Windows Firefox, Chrome and IE 8.
I'm having major problems in IE 7 though. Whilst the CSS is pretty much there (a few tweaks needed), the site is maxing out my CPU at 100% rendering the site almost unusable and giving me scripting errors and javascript functionality is not working.
I don't even know where to start trying to find out what's maxing out the CPU, or how to get more info on the scripting messages - it tells me the line the problem is on but it doesn't tell me what file.
I'd like to provide a link but the client has asked me not to.
Any help would be greatly appreciated.
Thank you
Most likely, this issue is caused by ie's poor png rendering capabilities. In the situation that I have experienced, we were using jquery ui 1.8.7 to render modal dialogs and seeing the memory usage spike by 6-8 mega every time a dialog box was opened. It turns out that the culprit was the opacity and alpha CSS settings in the default jquery styles. See this post for a possible partial fix.
Other things to note include:
There seem to be many fixes that attempt to address this issue.
Jquery 1.8.16 has a partial fix where the large memory jump will only happen when the first dialog box is opened.
We have also experimented by setting a single pixel png as the modal background and this rendering of a single pixel caused the memory used by IE to spike 80 megs and caused a temporary spike in CPU usage.
One other peculiar observation was that if we set the modal value of the jquery dialog to false and created our own modal background by appending a div whose background was set to a semi-transparent png, the memory leak seemed to be smaller.
The short of it was to stop using transparent pngs and the opacity and alpha settings foe rendering in IE.

Categories