add support for Opera transitions #4521

chrisben opened this Issue Jun 15, 2012 · 15 comments


None yet

8 participants


While checking the JQM doc pages ('1.1.0' or 'test') on Opera 12 I found that navigating to another page shows an empty page (then a click on the browser back button shows another empty page). If the destination page is reloaded though it shows the page correctly.

When the first page loads, the "Scripts" developer panel shows a :

 Unhandled DOMException: SYNTAX_ERR

in jquery code with this call stack (sorry minified code there):

m jquery-1.7.1.min.js:3
find jquery-1.7.1.min.js:3
f.Callbacks jquery-1.7.1.min.js:2
fireWith jquery-1.7.1.min.js:2
ready jquery-1.7.1.min.js:2
B jquery-1.7.1.min.js:2

Maybe this is not related to the above navigation problem by the way..

Not sure if that's a jquery problem, a JQM one or Opera..

Tested using Opera 12.00 Build 1467 for Linux (Opera Turbo Off and On : same problem).

Update: Problem not reproduced in opera 12 mobile on Android ICS.


I can confirm this issue.
On Windows I tested Opera 11.x: no problems
Updated to Opera 12: JQM sites (not only docs, but any) show a blank page after Ajax navigation

The console shows an error in jQuery:

Unhandled DOMException: SYNTAX_ERR

jQuery 1.7.1 line 5071 / 1.7.2 line 5163

return makeArray( context.querySelectorAll( "[id='" + nid + "'] " + query ), extra );

Besides Dragonfly shows hundreds of "unknown property" errors in CSS


Confirmed. Same issue on opera 12

sehe commented Jun 18, 2012

Confirmed. Same issue, opera build 1467 upgrade. Sites like don't render at all. Same exception Unhandled DOMException: SYNTAX_ERR


OK, that took a little bit to wrap my head around due to a Dragonfly setting (Settings > Scripts > Show Parse Errors and Break on Exceptions, trying to get that to default to off, but that's another story).

The actual issue seems to be two-fold: lack of -o- keyframes and other animation properties (which we added support for in 12), and a mismatch between the OAnimationEnd event type being oanimationend. :/// The better news is we're unprefixing these properties right now internally, so this issue will be a non-issue soon (which means the workaround code could be removed in a release or two).

Let me quote from internal discussion for more context:

Happened in c-i-274, yes. contains this code:

$.fn.animationComplete = function( callback ) {
if( $.support.cssTransitions ) { return $( this ).one( 'webkitAnimationEnd animationend', callback ); }
else{ (...) }

which has no support for Opera (the required keyframes and such with o prefix are also missing in, and adding OAnimationEnd doesn't help either. This is due to the OAnimationEnd event type being oanimationend (all lower-case), causing a mismatch when jQuery tries to dispatch the oanimationend event instead of OAnimationEnd. In Chrome, the webkitAnimationEnd event's type is webkitAnimationEnd.

This can be worked around by changing the above code to

$.fn.animationComplete = function( callback ) {
if( $.support.cssTransitions ) { return $( this ).one( 'webkitAnimationEnd OAnimationEnd oanimationend animationend', callback ); }
else{ (...) } }

and adding some useful o keyframes and animations to the mentioned CSS file.

I've just confirmed locally that this does in fact fix the page-goes-blank problem. Thanks for the heads up and sorry for the confusion.


For reference: #1883

sergeyi commented Jun 27, 2012

Are there any fixes planned?
Temporarily solution is to set $.support.cssTransitions = false;


Update: changed the topic of the issue


The event type has been changed from OAnimationEnd to oanimationend.


Transitions doesn't work yet on Opera because it doesn't support 3D transforms. Let's reopen when this is supported.


So you need to have 3d transforms to get any transition? Weird.


@miketaylr - we use 3D support internally as a less-than-ideal diagnostic of a browser's ability to run complex animations smoothly. We introduced this as a way to kick poorly performing platforms like Android 2.x or WebOS from blinking and generally freaking out when attempting (and failing) to run transitions, even relatively simple 2D ones like slide or pop.

When 3D isn't supported, we kick in a fallback mechanism and default to showing a simple fade transitions which most platforms seem to do a decent job with. All of this is configurable, but these are the defaults.

If Opera mobile doesn't support 3D animations, it's probably not worth adding all this code. If you're moving soon to non-prefixed keyframe animations, I'd rather add those and gain both Opera and IE10 support with one set of properties. What do you think?


@miketaylr @toddparker

I disabled the 3D-transforms support check to test the transitions on Opera desktop and I have to say they animate far less smooth then on Chrome and Firefox. That includes the "fade" transition. Only exception is "slide" which looks good. The "flip" and "turn" transitions don't work.

If you like you can pull opera-transitions to try them out yourself.

Ruffio commented Nov 10, 2014

@jaspermdegroot after two years I think you should reconsider to include Opera in 3d transitions again. I have just tried to run all the transitions by using the standard demo site ( and I my eyes it looks good. I havn't tryied OperaMini.

While reviewing the transform3dTest you should also consider to change from:
if ( ret ) {
return !!ret;


if ( ret ) {
return true;



Thanks for the pointer. Actually it is included already and transitions work on Opera and Opera Mobile. Opera Mini doesn't support 3D transitions.
With commit 749c78e the var opera has (accidently?) been removed in support.js so the && !opera that was added to exclude Opera doesn't do anything anymore. For the versions of Opera (Mobile) that we support we don't need to add -o- prefixed properties in the CSS.
What we need to do is removing that useless && !opera.

@jaspermdegroot jaspermdegroot added this to the 1.5.0 milestone Nov 13, 2014

Actually & !opera was removed with the same commit: 749c78e#diff-07cac4035b048ed039811db6b43d4d5dL211. Closing as resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment