As part of a school project, I have DIVs that I need to be able to move. I have it working, and it works perfectly in Firefox. However, in other browsers, it doesn't really work that well. In IE9, it doesn't work at all. In Safari, it lags, even when only one div is up. In Opera and Chrome, it works fine when there's only one div, but if there are several divs on top of each other, and I try to move one over the others, it lags.
I've been going at it for a while, and I've really run out of ideas as to what could cause it.
As this is for school, we're not allowed to use any libraries (as this would have simplified it quite a bit).
The code for making divs draggable is here: http://pastebin.com/4TGRg1AW
Are you not allowed to use something like jQuery? It takes care of a lot of js browser compatibility issues.
Related
I am trying to create an animation-heavy presentation using impress.js. On chrome, its coming out awesome and really smooth. But, when I run it on firefox, the presentation looks really really bad.
Problems -
Elements which are at the back of the front elements (creating a 3D View) can always be seen merging into the front elements. ( some kind of transparency issues )
Transition from one slide to another is sluggish. Even their own demo is not as smooth on Firefox as it is on Chrome. ( Their DEMO )
I have put about 30 steps in my presentation, and a lot of times, firefox just crashes completely.
If anyone faced with similar problems with firefox and impress.js and found solutions, please help!
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.
I'm currently fighting a very frustrating bug on Safari, and I'm not sure where else to turn.
It seems most elements (but not all, and I can't discern the differentiating factor) that will trigger a focus event will cause all elements on the page that are transitioned or animated to jump ~2px to the top and left. And this only occurs on the first focus event after the page loads.
It's a little annoying to see the bug, as it's in the logged-in portion of droplr.com, and I have been completely unable to distill down a simpler case on JSFiddle.
If you have/create an account and log-in, click on this edit icon for a drop:
You'll see that on the first focus of the page, things jitter. Here's the timeline when there's a single drop on the page and I trigger focus on an offending element:
With more drops, it's just more of the same, but it seems to max out around 40 paints. And the profiler doesn't suggest anything nefarious. Just a trip through jQuery internals.
If instead of laying elements out via a translate3d or matix3d, I simply use top and left, this bug goes away. After hours and hours of debugging this, I'm at a complete loss.
Hoping someone has seen something similar, could take a look, or could give me advice on debugging next steps.
Thanks so much!
Update: Dave Desandro suggested it was the 3d acceleration kicking in, so I tried it out with a translate instead, and sure enough, that did not cause the jitter. I have no idea why the hardware acceleration would be firing up with a focus event though, and only once.
I've tried setting a transformZ of 0 on page load to go ahead and ramp-up the hardware, but no luck there, either. Any more ideas are welcomed.
I've had this issue a while back and honestly I don't remember what exactly was the cause but here are some of the steps I followed:
Check that you don't have hide() and show() for the same element in the next line or vice versa.
Example:
el.show()
el.hide()
Change Custom fonts to "Arial"
For the elements you don't want focus events add this code at the bottom of your scripts:
noFocusElem.off('focus');
This will make sure to remove any focus handlers you might have added by mistake
Finally place your css before any scripts. It's a know fact that adding css rules after an inline style has been applied may cause jitter especially if you're using line-hieght property
Hope this helps :)
I've had this happen when using custom font kits. Could this be the issue? Some events cause custom fonts to re-draw, which can cause a ever so slight "jitter" in page display.
Sometimes, manually setting heights and widths on all the parent HTML elements can reduce the flicker.
I know this question was posted a while ago and this is a bit of a long shot but here goes:
Maybe as a starting point go back to chrome and look at the composite layering:
Hit this into the address bar:
about:flags
You will be able to enable composite borders from within there. The red borders generally indicate a rendering issue:
http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome
What I have found from time to time is that although there are rendering issues in Chrome the browser copes pretty well with hiding them from me. In other webkit based browsers however the result can be more noticable (i.e. android).
I've also seen flickering occur when z-indexes are being used in conjunction with content that is being transformed.
Either way it would be great to know how you resolved this issue (if you did). Post an answer to your own question perhaps?
A way to avoid spending time fixing load time twitches; you could set the page to hidden then make elements visible with the load. If your page is slow to load, you may want to have a spinner default to visible, then have load hide it. Then you could come back to the issue when you have nothing better to do.
Just my 2c worth.
The first thing I would try:
First in chrome, whack in 'about:flags' (yes I know you're not using Chrome). Find the 'Composited render layer borders' and turn it on. Once this feature is switched on you'll get a rough idea of what is being rendered/hardware accelerated.
See: http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome
and look for any rendering problems. These are normally caused by z-indexes. Play around with any z-indexes and hide/show certain elements until the rendering issues are resolved. Then work from there. translate-z hacks and opacity can also cause problems.
From experience I've found rendering problems in other webkit browsers can be diagnosed using chrome. Flickering is a common occurrence on the stock android browser.
Secondly: take a look at the focus event itself and try things like preventing the default behaviour. Seems like a long shot to me but give it a go.
I haven't tested this, so I will be very surprised if it works... but here's an idea:
$(document).ready(function() {
$(document).focus(function(e) {
e.preventDefault();
});
$(document).click(function() {
$(document).unbind();
});
});
I've been running into the same issue recently and found something that fixed it in my case.
Check for anything that's hidden offscreen like:
text-indent: -9999px;
left: -9999px;
Removing any instance of these from the 3d accelerated elements (including children) stopped the content jump on focus for me.
With this project at work, we have had to make a iPad HTML5. Using Backbone and jQuery Mobile, we thought we were on to a winner, but jQuery Mobile seems to be causing more problems than it should be. Using such things as page transitions with jQuery Mobile is painfully slow, choppy and glitchy (I do understand it's still in Alpha).
For our needs, we do want a smooth way of transitions between pages. I set about doing some experiments to see if I could get them any better for bespoke solution. I feel I'm quite close with this, but the animations still seem choppy and glitchy. I wonder if there is any other way to approach this? Or if there is a nugget of information that will help getting this rock solid?
I'm using translateX()/translateY() CSS3 (hardware accelerated) transforms to ensure it gets the best performance, but it still seems unreliable with it's performance. Sometimes it's ok, sometimes it's not.
I have uploaded an example... Please note, this is only tested in Chrome/Safari (which it looks fine in) and Mobile Safari on the iPad 1st generation (which it looks choppy in). If you happen to have an iPad handy, please take a look at this example...
http://littlejim.co.uk/code/ipad/jquery-plugin-page-transitions/
It's made as a basic plugin, because once I have this nailed I want to develop it more.
Can anyone help with this? I just wonder why it's still choppy on the iPad?
UPDATE: I tried using translate3d() as well as the translateX and translateY(), made no difference.
Only 3 dimensional transforms are hardware accelerated on the iPad. You should use translate3d and provide a 3rd parameter, set to zero.
http://googlecode.blogspot.com/2010/08/css3-transitions-and-transforms-in.html
I want to make a mini timeline with jquery and for this timeline to have a width more than 32767 px. When I change it with jquery $(".timelinecontainer").width(32767); in Opera does not change it, but in others browsers it works.
Can you give me advice on getting it to work in Opera ?
I suspect that Opera keeps the window width as a short and thus is not able to handle values larger than 32767. You should probably change your approach anyway and scale the timeline to fit the current window, then give the ability to zoom in on portions of it. I think your interface will look and work better this way. The way you seem to be doing it, the user will have to do a lot of scrolling to view the timeline and won't ever be able to see it in its entirety.
I'm sure I'll get flamed for saying this but--you could just ignore Opera.
If you like how things look in the other browsers (IE,FF,Safari/Chrome), then I'd say you've got 99% of your bases covered.
You may want to file a bug against Opera, of course. (though I guess it could be jquery--it may have a different code path for Opera). If you could make a simple HTML page to reproduce the problem, you'd know. Then, attach it to the bug report.
This is a very old Opera bug which for some reason they can't resolve. Opera is popular only in some regions and mostly this bug is ignored by the developers.
There is no automated solution for this. As a quick solution you can detect web-browser in your script and limit the width for Opera. As an example - scroll this guitar tab to an end in Opera.
I can confirm that this is indeed a bug in the current Opera versions. The good news is that we're working on fixing it (I work for Opera, so I know what's going on there :)), so in the not too distant future your script should start working as you expect.
I'd actually suggest that if the workaround the first answer above suggests is too hard to implement, you should ignore the problem and wait for the Opera upgrade that fixes it.
This is a bug and it has been fixed in the Opera 12 pre-alphas available from http://my.opera.com/desktopteam
This is definitely a bug with Opera.
Coincidentally, I was seeing it for the first time just yesterday. In my situation I have an inner container with width:9999em and an outer container that uses overflow:hidden and scrollLeft() to create a carousel. In Opera the scrollLeft() stops responding at that width.
File a bug with Opera: https://bugs.opera.com/wizard/
Sounds like an Opera bug to me, too.
Why not take a look at Simile's Timeline project (http://simile.mit.edu/timeline/) and see how they've done it?