JQM interfering with the Chrome and Firebug debuggers #4206

Closed
rhardgrave opened this Issue Apr 25, 2012 · 15 comments

Comments

Projects
None yet
4 participants
@jblas

This comment has been minimized.

Show comment
Hide comment
@jblas

jblas Apr 25, 2012

Contributor

Do you have an example file we can use to see the problem? Are the breakpoints in a script tag within the HTML file? Or is it within one of your own external JS files? Please try to be as detailed as possible. Also, do things work properly if you use the non-minified version of the jQuery Mobile file?

Contributor

jblas commented Apr 25, 2012

Do you have an example file we can use to see the problem? Are the breakpoints in a script tag within the HTML file? Or is it within one of your own external JS files? Please try to be as detailed as possible. Also, do things work properly if you use the non-minified version of the jQuery Mobile file?

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Apr 27, 2012

Contributor

@rhardgrave - we need more details to debug this or we'll have to close.

Contributor

toddparker commented Apr 27, 2012

@rhardgrave - we need more details to debug this or we'll have to close.

@rhardgrave

This comment has been minimized.

Show comment
Hide comment
@rhardgrave

rhardgrave Apr 30, 2012

Sorry for the delay, I'll get something up to debug this sometime this week.

Sorry for the delay, I'll get something up to debug this sometime this week.

@rhardgrave

This comment has been minimized.

Show comment
Hide comment
@rhardgrave

rhardgrave May 1, 2012

Here is a sample of what I'm seeing. In the main.js file you'll see a conversations and connect function that get called when you hit the home and connect buttons on the app. You'll see the console.log statements working in Firebug/Chrome. However, if you put a breakpoint on each log statement, they won't work. I tried Google Chrome 18 and FF 11. Thanks for any help you can provide.

http://www.standardsofethicalconduct.com/jqmdebug/index.html

Here is a sample of what I'm seeing. In the main.js file you'll see a conversations and connect function that get called when you hit the home and connect buttons on the app. You'll see the console.log statements working in Firebug/Chrome. However, if you put a breakpoint on each log statement, they won't work. I tried Google Chrome 18 and FF 11. Thanks for any help you can provide.

http://www.standardsofethicalconduct.com/jqmdebug/index.html

@rhardgrave

This comment has been minimized.

Show comment
Hide comment
@rhardgrave

rhardgrave May 1, 2012

@JBIAS, here are the answers: I've tried just the minified version of JQM. The breakpoints are in an external JS file as you'll see in the sample above (main.js).

@JBIAS, here are the answers: I've tried just the minified version of JQM. The breakpoints are in an external JS file as you'll see in the sample above (main.js).

@jblas

This comment has been minimized.

Show comment
Hide comment
@jblas

jblas May 1, 2012

Contributor

Ok, I see what's going on. Your page contains nothing but script tags in the body. When jQuery Mobile initializes, it notices that the body contains no data-role="page" divs in it so it wraps the entire contents of the body within a page div. Now jQuery Mobile is using jQuery's wrapAll() method to do this, apparently part of that implementation looks for any script tags inside the content being wrapped, and it then loads each script source via XHR ... so the browser ends up loading the scripts twice, confusing the debugger.

Cc: @toddparker @scottjehl @johnbender @gseguin

Contributor

jblas commented May 1, 2012

Ok, I see what's going on. Your page contains nothing but script tags in the body. When jQuery Mobile initializes, it notices that the body contains no data-role="page" divs in it so it wraps the entire contents of the body within a page div. Now jQuery Mobile is using jQuery's wrapAll() method to do this, apparently part of that implementation looks for any script tags inside the content being wrapped, and it then loads each script source via XHR ... so the browser ends up loading the scripts twice, confusing the debugger.

Cc: @toddparker @scottjehl @johnbender @gseguin

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker May 1, 2012

Contributor

Huh, interesting. So this seems like an edge case that could be addressed with a note in the docs perhaps? Is all that's needed is any HTML tag in the body?

Contributor

toddparker commented May 1, 2012

Huh, interesting. So this seems like an edge case that could be addressed with a note in the docs perhaps? Is all that's needed is any HTML tag in the body?

@rhardgrave

This comment has been minimized.

Show comment
Hide comment
@rhardgrave

rhardgrave May 1, 2012

I stuck the following into the body of my html page and it solved the problem:

<div data-role="page"></div>

An empty div without the data-role attribute didn't solve it, so I added the data-role attribute.

Thanks for the quick turnaround on this, you guys rock.

I stuck the following into the body of my html page and it solved the problem:

<div data-role="page"></div>

An empty div without the data-role attribute didn't solve it, so I added the data-role attribute.

Thanks for the quick turnaround on this, you guys rock.

@jblas

This comment has been minimized.

Show comment
Hide comment
@jblas

jblas May 1, 2012

Contributor

@toddparker

As @rhardgrave mentioned, the framework has to find at least one element with a data-role="page" in the body, or it will assume that you wanted the whole body to be "the page". Scott added this a while back as a convenience so we could suck in external pages that weren't "jQM" ready.

Contributor

jblas commented May 1, 2012

@toddparker

As @rhardgrave mentioned, the framework has to find at least one element with a data-role="page" in the body, or it will assume that you wanted the whole body to be "the page". Scott added this a while back as a convenience so we could suck in external pages that weren't "jQM" ready.

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker May 1, 2012

Contributor

Right, makes sense. So do we need to add a note in the docs somewhere, if so, what should be added?

On May 1, 2012, at 6:11 PM, "Kin Blas" reply@reply.github.com wrote:

@toddparker

As @rhardgrave mentioned, the framework has to find at least one element with a data-role="page" in the body, or it will assume that you wanted the whole body to be "the page". Scott added this a while back as a convenience so we could suck in external pages that weren't "jQM" ready.


Reply to this email directly or view it on GitHub:
#4206 (comment)

Contributor

toddparker commented May 1, 2012

Right, makes sense. So do we need to add a note in the docs somewhere, if so, what should be added?

On May 1, 2012, at 6:11 PM, "Kin Blas" reply@reply.github.com wrote:

@toddparker

As @rhardgrave mentioned, the framework has to find at least one element with a data-role="page" in the body, or it will assume that you wanted the whole body to be "the page". Scott added this a while back as a convenience so we could suck in external pages that weren't "jQM" ready.


Reply to this email directly or view it on GitHub:
#4206 (comment)

@jblas

This comment has been minimized.

Show comment
Hide comment
@jblas

jblas May 1, 2012

Contributor

Yeah, I think we need to document this auto-wrapping page behavior if it isn't already, and add a nice big warning about what I described above in regards to our use of jQuery Core's wrapAll() which has the side effect of loading any script tags again.

Contributor

jblas commented May 1, 2012

Yeah, I think we need to document this auto-wrapping page behavior if it isn't already, and add a nice big warning about what I described above in regards to our use of jQuery Core's wrapAll() which has the side effect of loading any script tags again.

@agcolom

This comment has been minimized.

Show comment
Hide comment
@agcolom

agcolom May 26, 2012

Member

@toddparker @jblas Would the following be ok for the docs?

Note: If your body contains no data-role="page" divs, jQuery Mobile wraps the entire contents of the body within a page div. jQuery Mobile is using jQuery's wrapAll() method to do this which looks for any script tags inside the content being wrapped, and loads each script source via XHR. If scripts are present in the body, the browser ends up loading them twice. We therefore strongly recommend that jQuery Mobile documents with scripts in their body also contain a div with data-role="page".

Member

agcolom commented May 26, 2012

@toddparker @jblas Would the following be ok for the docs?

Note: If your body contains no data-role="page" divs, jQuery Mobile wraps the entire contents of the body within a page div. jQuery Mobile is using jQuery's wrapAll() method to do this which looks for any script tags inside the content being wrapped, and loads each script source via XHR. If scripts are present in the body, the browser ends up loading them twice. We therefore strongly recommend that jQuery Mobile documents with scripts in their body also contain a div with data-role="page".

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker May 27, 2012

Contributor

That looks great. Whee do you think it should go? Anatomy of a page? Scripting pages?

Contributor

toddparker commented May 27, 2012

That looks great. Whee do you think it should go? Anatomy of a page? Scripting pages?

@agcolom

This comment has been minimized.

Show comment
Hide comment
@agcolom

agcolom May 27, 2012

Member

@toddparker I'm tempted to go with Anatomy of a page as scripting pages already has something along those lines... what do you think?

Member

agcolom commented May 27, 2012

@toddparker I'm tempted to go with Anatomy of a page as scripting pages already has something along those lines... what do you think?

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker May 27, 2012

Contributor

@agcolom Sounds good to me.

Contributor

toddparker commented May 27, 2012

@agcolom Sounds good to me.

@agcolom agcolom closed this in a2a2b36 May 28, 2012

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