Skip to content
This repository

add support for Opera transitions #4521

chrisben opened this Issue June 15, 2012 · 12 comments

7 participants

chrisben Jasper de Groot soncemvo sehe Mike Taylor sergeyi Todd Parker

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.

Jasper de Groot

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 June 18, 2012

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

Mike Taylor

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.

Jasper de Groot

For reference: #1883


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

Jasper de Groot uGoMobi closed this in 29c654e June 27, 2012
Jasper de Groot uGoMobi reopened this July 26, 2012
Jasper de Groot

Update: changed the topic of the issue

Elliot Smith townxelliot referenced this issue from a commit July 30, 2012
Commit has since been removed from the repository and is no longer available.
Jasper de Groot

The event type has been changed from OAnimationEnd to oanimationend.

Jasper de Groot uGoMobi referenced this issue from a commit in uGoMobi/jquery-mobile August 09, 2012
Jasper de Groot Transitions: Added support for Opera transitions. Fixes #4521. 417bf0c
Jasper de Groot uGoMobi closed this August 26, 2012
Jasper de Groot

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

Mike Taylor

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

Todd Parker

@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?

Jasper de Groot

@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.

masonzhang masonzhang referenced this issue from a commit June 27, 2012
Jasper de Groot Fixes #4521 - Exclude Opera from support.cssTransitions as long as we…
… are not ready to support it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.