New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add support for Opera transitions #4521

Closed
chrisben opened this Issue Jun 15, 2012 · 15 comments

Comments

Projects
None yet
8 participants
@chrisben

chrisben commented Jun 15, 2012

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
a.find jquery.mobile-1.1.0.min.js:25
find jquery-1.7.1.min.js:3
a.mobile.focusPage jquery.mobile-1.1.0.min.js:51
jquery.mobile-1.1.0.min.js:40
jquery.mobile-1.1.0.min.js:41
f jquery.mobile-1.1.0.min.js:42
a.mobile.changePage jquery.mobile-1.1.0.min.js:63
initializePage jquery.mobile-1.1.0.min.js:175
jquery.mobile-1.1.0.min.js:176
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.

@jaspermdegroot

This comment has been minimized.

Show comment
Hide comment
@jaspermdegroot

jaspermdegroot Jun 15, 2012

Member

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

Member

jaspermdegroot commented Jun 15, 2012

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

@soncemvo

This comment has been minimized.

Show comment
Hide comment
@soncemvo

soncemvo Jun 17, 2012

Confirmed. Same issue on opera 12

soncemvo commented Jun 17, 2012

Confirmed. Same issue on opera 12

@sehe

This comment has been minimized.

Show comment
Hide comment
@sehe

sehe Jun 18, 2012

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

sehe commented Jun 18, 2012

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

@miketaylr

This comment has been minimized.

Show comment
Hide comment
@miketaylr

miketaylr Jun 20, 2012

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. http://jquerymobile.com/test/js/jquery.mobile.js 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 http://jquerymobile.com/test/css/themes/default/jquery.mobile.css), 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.

miketaylr commented Jun 20, 2012

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. http://jquerymobile.com/test/js/jquery.mobile.js 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 http://jquerymobile.com/test/css/themes/default/jquery.mobile.css), 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.

@jaspermdegroot

This comment has been minimized.

Show comment
Hide comment
@jaspermdegroot

jaspermdegroot Jun 21, 2012

Member

For reference: #1883

Member

jaspermdegroot commented Jun 21, 2012

For reference: #1883

@sergeyi

This comment has been minimized.

Show comment
Hide comment
@sergeyi

sergeyi Jun 27, 2012

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

sergeyi commented Jun 27, 2012

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

@jaspermdegroot

This comment has been minimized.

Show comment
Hide comment
@jaspermdegroot

jaspermdegroot Jul 26, 2012

Member

Update: changed the topic of the issue

Member

jaspermdegroot commented Jul 26, 2012

Update: changed the topic of the issue

@jaspermdegroot

This comment has been minimized.

Show comment
Hide comment
@jaspermdegroot

jaspermdegroot Aug 9, 2012

Member

The event type has been changed from OAnimationEnd to oanimationend.

Member

jaspermdegroot commented Aug 9, 2012

The event type has been changed from OAnimationEnd to oanimationend.

@jaspermdegroot

This comment has been minimized.

Show comment
Hide comment
@jaspermdegroot

jaspermdegroot Aug 26, 2012

Member

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

Member

jaspermdegroot commented Aug 26, 2012

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

@miketaylr

This comment has been minimized.

Show comment
Hide comment
@miketaylr

miketaylr Aug 27, 2012

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

miketaylr commented Aug 27, 2012

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

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Aug 27, 2012

Contributor

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

Contributor

toddparker commented Aug 27, 2012

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

@jaspermdegroot

This comment has been minimized.

Show comment
Hide comment
@jaspermdegroot

jaspermdegroot Aug 27, 2012

Member

@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 https://github.com/uGoMobi/jquery-mobile.git opera-transitions to try them out yourself.

Member

jaspermdegroot commented Aug 27, 2012

@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 https://github.com/uGoMobi/jquery-mobile.git opera-transitions to try them out yourself.

@Ruffio

This comment has been minimized.

Show comment
Hide comment
@Ruffio

Ruffio 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 (http://demos.jquerymobile.com/1.4.5/transitions/) 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;
}

to:

if ( ret ) {
return true;
}

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 (http://demos.jquerymobile.com/1.4.5/transitions/) 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;
}

to:

if ( ret ) {
return true;
}

@jaspermdegroot

This comment has been minimized.

Show comment
Hide comment
@jaspermdegroot

jaspermdegroot Nov 13, 2014

Member

@Ruffio

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.

Member

jaspermdegroot commented Nov 13, 2014

@Ruffio

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

@jaspermdegroot

This comment has been minimized.

Show comment
Hide comment
@jaspermdegroot

jaspermdegroot Feb 5, 2015

Member

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

Member

jaspermdegroot commented Feb 5, 2015

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