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

Comments form causes mobile browser crash with certain themes #540

Closed
richardmtl opened this Issue May 14, 2014 · 7 comments

Comments

Projects
None yet
6 participants
@richardmtl
Member

richardmtl commented May 14, 2014

I have 2 reports of this:

https://wordpress.org/support/topic/jetpack-comments-with-decode-crashes-browser-on-ios-devices?replies=4

uses Decode, from the theme repo.

http://wordpress.org/support/topic/crashes-ios-browsers?replies=6#post-5577994

Uses Akita, from Themeforest.

I was able to reproduce with Decode. With Minileven off, the mobile browser crashes only when Jetpack's Comment module is active. This does not happen on the Twenty themes.

I did not test Akita.

@richardmtl richardmtl added bug labels May 14, 2014

@richardmtl

This comment has been minimized.

Show comment
Hide comment
@richardmtl

richardmtl May 14, 2014

Member

To add, I tested with Safari and Chrome on iOS7

Member

richardmtl commented May 14, 2014

To add, I tested with Safari and Chrome on iOS7

@kraftbj

This comment has been minimized.

Show comment
Hide comment
@kraftbj

kraftbj May 15, 2014

Contributor

Confirmed on Safari/Chrome on iPad, iOS 7. I pulled the crashlog.

Perhaps, this is a bug in Webkit outside our realm to fix, since it doesn't occur in on other operating systems.

Contributor

kraftbj commented May 15, 2014

Confirmed on Safari/Chrome on iPad, iOS 7. I pulled the crashlog.

Perhaps, this is a bug in Webkit outside our realm to fix, since it doesn't occur in on other operating systems.

@richardmtl

This comment has been minimized.

Show comment
Hide comment
@richardmtl

richardmtl Jun 5, 2014

Member

From http://wordpress.org/support/topic/jetpack-comments-with-decode-crashes-browser-on-ios-devices?replies=10#post-5656200 :

I have located the CSS properties that are causing this issue. In the Decode theme's style.css file, the comment-form class contains the following two properties at the beginning of the class:

display:-webkit-box;
display:-webkit-flex;

Commenting out these two properties from the comment-form class fixes the problem. If either of these properties are present in the comment-form class AND Jetpack Comments are enabled, the crash occurs.

This narrows down the problem considerably, although it still does not pinpoint the specific conflict between Decode and Jetpack Comments.

I agree that this seems like a Webkit bug but I can't find a related bug report for Webkit.

Member

richardmtl commented Jun 5, 2014

From http://wordpress.org/support/topic/jetpack-comments-with-decode-crashes-browser-on-ios-devices?replies=10#post-5656200 :

I have located the CSS properties that are causing this issue. In the Decode theme's style.css file, the comment-form class contains the following two properties at the beginning of the class:

display:-webkit-box;
display:-webkit-flex;

Commenting out these two properties from the comment-form class fixes the problem. If either of these properties are present in the comment-form class AND Jetpack Comments are enabled, the crash occurs.

This narrows down the problem considerably, although it still does not pinpoint the specific conflict between Decode and Jetpack Comments.

I agree that this seems like a Webkit bug but I can't find a related bug report for Webkit.

@ScottSmith95

This comment has been minimized.

Show comment
Hide comment
@ScottSmith95

ScottSmith95 Jun 5, 2014

This does seem like a WebKit bug, the crash report makes it seem that way as well. It clearly has to do with Flexbox, a new spec that's not as well tested. Does Jetpack load any JS for the comments form? If so, where can I find it?

ScottSmith95 commented Jun 5, 2014

This does seem like a WebKit bug, the crash report makes it seem that way as well. It clearly has to do with Flexbox, a new spec that's not as well tested. Does Jetpack load any JS for the comments form? If so, where can I find it?

@isaacrthorne

This comment has been minimized.

Show comment
Hide comment
@isaacrthorne

isaacrthorne Jun 6, 2014

I have more information about this issue that might be of help.

Decode has a DIV element named "commentform" that is styled with a class named "comment-form". The source of the IFRAME that Jetpack returns to replace Wordpress comments contains a FORM element named "commentform" that is styled with a class named "comment-form". Having discovered that, I set up the following test:

I created a plain HTML file named test.html that contains the following markup:

<html>
<head>
<title>Webkit CSS and IFRAME Test Page</title>
<style type="text/css">
.comment-form
{
   display:-webkit-box;
   display:-webkit-flex;
}
</style>
</head>
<body>
<div id="commentform" class="comment-form">
<iframe src="/formtest.html" "allowtransparency="true" style="width:100%; height: 430px;border:0px;" frameBorder="0" scrolling="no" name="jetpack_remote_comment" id="jetpack_remote_comment"></iframe>
</div>
</body>
</html>

I created another plain HTML page named "formtest.html" that contains an exact copy of the source of the comment form IFRAME returned by Jetpack. It's a lot of code, so I won't repost here. Loading my "test.html" file in Chrome on iOS 7 produced the crash.

Suspecting that the Jetpack code performs some JavaScript/jQuery magic on the form returned in the IFRAME (that you'll recall has the same name/class as the Decode DIV), I started testing by commenting out all sections of JavaScript in formtest.html and then uncommenting and testing the page load script-by-script until the crash occurred.

Ultimately, I discovered that if the following section of JavaScript is commented out, the crash DOES NOT occur:

            <script type="text/javascript">
  var highlander_expando_javascript = function(){
    var input = document.createElement( 'input' ),
        comment = jQuery( '#comment' );

    if ( 'placeholder' in input ) {
        comment.attr( 'placeholder', jQuery( '.comment-textarea label' ).remove().text() );
    }

    // Expando Mode: start small, then auto-resize on first click + text length
    jQuery( '#comment-form-identity' ).hide();
    jQuery( '#comment-form-subscribe' ).hide();
    jQuery( '#commentform .form-submit' ).hide();

    comment.css( { 'height':'10px' } ).one( 'focus', function() {
        var timer = setInterval( HighlanderComments.resizeCallback, 10 )
        jQuery( this ).animate( { 'height': HighlanderComments.initialHeight } ).delay( 100 ).queue( function(n) { clearInterval( timer ); HighlanderComments.resizeCallback(); n(); } );
        jQuery( '#comment-form-identity' ).slideDown();
        jQuery( '#comment-form-subscribe' ).slideDown();
        jQuery( '#commentform .form-submit' ).slideDown();
    });
}
jQuery(document).ready( highlander_expando_javascript );
</script>

I believe this is the section of code that performs the animation on the Jetpack comment form when the user first clicks inside the text area. I don't presume to know, but I wonder if this issue could be fixed by more specifically referencing the IFRAME source FORM element's ID in the JavaScript instead of referencing it by element ID alone.

Hope this helps. Thank you.

isaacrthorne commented Jun 6, 2014

I have more information about this issue that might be of help.

Decode has a DIV element named "commentform" that is styled with a class named "comment-form". The source of the IFRAME that Jetpack returns to replace Wordpress comments contains a FORM element named "commentform" that is styled with a class named "comment-form". Having discovered that, I set up the following test:

I created a plain HTML file named test.html that contains the following markup:

<html>
<head>
<title>Webkit CSS and IFRAME Test Page</title>
<style type="text/css">
.comment-form
{
   display:-webkit-box;
   display:-webkit-flex;
}
</style>
</head>
<body>
<div id="commentform" class="comment-form">
<iframe src="/formtest.html" "allowtransparency="true" style="width:100%; height: 430px;border:0px;" frameBorder="0" scrolling="no" name="jetpack_remote_comment" id="jetpack_remote_comment"></iframe>
</div>
</body>
</html>

I created another plain HTML page named "formtest.html" that contains an exact copy of the source of the comment form IFRAME returned by Jetpack. It's a lot of code, so I won't repost here. Loading my "test.html" file in Chrome on iOS 7 produced the crash.

Suspecting that the Jetpack code performs some JavaScript/jQuery magic on the form returned in the IFRAME (that you'll recall has the same name/class as the Decode DIV), I started testing by commenting out all sections of JavaScript in formtest.html and then uncommenting and testing the page load script-by-script until the crash occurred.

Ultimately, I discovered that if the following section of JavaScript is commented out, the crash DOES NOT occur:

            <script type="text/javascript">
  var highlander_expando_javascript = function(){
    var input = document.createElement( 'input' ),
        comment = jQuery( '#comment' );

    if ( 'placeholder' in input ) {
        comment.attr( 'placeholder', jQuery( '.comment-textarea label' ).remove().text() );
    }

    // Expando Mode: start small, then auto-resize on first click + text length
    jQuery( '#comment-form-identity' ).hide();
    jQuery( '#comment-form-subscribe' ).hide();
    jQuery( '#commentform .form-submit' ).hide();

    comment.css( { 'height':'10px' } ).one( 'focus', function() {
        var timer = setInterval( HighlanderComments.resizeCallback, 10 )
        jQuery( this ).animate( { 'height': HighlanderComments.initialHeight } ).delay( 100 ).queue( function(n) { clearInterval( timer ); HighlanderComments.resizeCallback(); n(); } );
        jQuery( '#comment-form-identity' ).slideDown();
        jQuery( '#comment-form-subscribe' ).slideDown();
        jQuery( '#commentform .form-submit' ).slideDown();
    });
}
jQuery(document).ready( highlander_expando_javascript );
</script>

I believe this is the section of code that performs the animation on the Jetpack comment form when the user first clicks inside the text area. I don't presume to know, but I wonder if this issue could be fixed by more specifically referencing the IFRAME source FORM element's ID in the JavaScript instead of referencing it by element ID alone.

Hope this helps. Thank you.

@isaacrthorne

This comment has been minimized.

Show comment
Hide comment
@isaacrthorne

isaacrthorne Jun 6, 2014

Another update.

I added a semicolon here in the Jetpack code in my formtest.html file:

    comment.css( { 'height':'10px;' } ).one( 'focus', function() {

The original code was:

    comment.css( { 'height':'10px' } ).one( 'focus', function() {

The addition of the semicolon appears to have fixed the problem, at least in my test form. Loading the page in Chrome for iOS 7 without the semicolon causes the crash. Loading the page in Chrome for iOS 7 with the semicolon loads the Jetpack comment form as it should.

Because the original source code comes down in an IFRAME, I have no way of testing this in my full production environment, so I do not know if adding the semicolon breaks anything else.

isaacrthorne commented Jun 6, 2014

Another update.

I added a semicolon here in the Jetpack code in my formtest.html file:

    comment.css( { 'height':'10px;' } ).one( 'focus', function() {

The original code was:

    comment.css( { 'height':'10px' } ).one( 'focus', function() {

The addition of the semicolon appears to have fixed the problem, at least in my test form. Loading the page in Chrome for iOS 7 without the semicolon causes the crash. Loading the page in Chrome for iOS 7 with the semicolon loads the Jetpack comment form as it should.

Because the original source code comes down in an IFRAME, I have no way of testing this in my full production environment, so I do not know if adding the semicolon breaks anything else.

@ScottSmith95

This comment has been minimized.

Show comment
Hide comment
@ScottSmith95

ScottSmith95 Sep 6, 2014

This seems to have been fixed on iOS 8, lending to the notion that this is a WebKit bug. I think the issue was WebKit would crash if display: flex (Well, the prefixed version of that) was placed on an element with an iframe as a child.

ScottSmith95 commented Sep 6, 2014

This seems to have been fixed on iOS 8, lending to the notion that this is a WebKit bug. I think the issue was WebKit would crash if display: flex (Well, the prefixed version of that) was placed on an element with an iframe as a child.

@samhotchkiss samhotchkiss modified the milestone: Needs Triage Aug 28, 2015

@jeherve jeherve modified the milestone: Needs Triage Feb 15, 2016

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