When I click on the Preview button in the add/edit node page. I get the following Firebug message:
$.cookie is not a function
http://localhost/drupal7/misc/tabledrag.js?ldbu1k
Line 168
I made some tests and I detect that this error is produced when in the add/edit node page there are one or more fields with unlimited possible values and the node form is in an overlay.
For example, when the URL is http://localhost/drupal7/node/7#overlay=node/7/edit, the Javascript error appears, but not in http://localhost/drupal7/node/7/edit
Regards
Comment | File | Size | Author |
---|---|---|---|
#7 | overlay-javascript-error-996240-7.patch | 1021 bytes | David_Rothstein |
Comments
Comment #1
droplet CreditAttribution: droplet commentedI'm not familiar with new API. what I seem is when the toolbar enabled, it loads jquery.cookie into page. When tabledrag called to load jquery.cookie, for some reason.. it prevent to load twice.
but overlay loading in iframe which do not share with same JS.
It's very common feature, affect lots user & cause usability issues
Comment #2
catchMoving to overlay.
Comment #3
unik CreditAttribution: unik commentedI have the same error message ($.cookie is not a function) pointing at line 168 of tabledrag.js every time i try to order items by handler but in my case it hapens even without the overlay (e.g. I get it in both #overlay=admin/structure/block and admin/structure/block pages).
Error exists even with both toolbar and overlay modules disabled so maybe this is not so overlay related?
...or I am in the wrong issue? :/
Comment #4
droplet CreditAttribution: droplet commented@unik,
same issue
Comment #5
unik CreditAttribution: unik commentedIs there any possibility that filenames like jquery.cookie.js cause this kind of errors?
I just discover that my server shows me (on browser) files like http://domain.com/misc/jquery.js but not those with a dot in its filenames (like http://domain.com/misc/jquery.cookie.js )
Comment #6
casey CreditAttribution: casey commentedI cannot reproduce on an clean installation.
Do you have cache enabled?
Do you have javascript aggregation enabled?
Do you have extra modules installed? Which?
Are you logged in as an admin user (with all permissions)?
Comment #7
David_Rothstein CreditAttribution: David_Rothstein commentedThe original bug report is easy to reproduce. (@unik's issue seems like a different problem, and I wasn't able to reproduce that one either.)
Here is a patch for the original bug.
This could probably use a test. But on the other hand, the whole overlay module doesn't have any tests, and I'm personally not willing to break that bad pattern right this moment, although it would be a good idea for someone to break it at some point :)
Comment #8
unik CreditAttribution: unik commentedIt seems that I have a different problem after all...
Sorry for confusing anyone with my issue
Comment #9
bdragon CreditAttribution: bdragon commentedSubscribing.
Seems to work ok for an issue I was just having with overlay.
Comment #10
Lars Toomre CreditAttribution: Lars Toomre commentedDoesn't the drupal_static in the $original_libraries definition need a missing & (ie &drupal_static)?
Comment #11
David_Rothstein CreditAttribution: David_Rothstein commentedNo, because we want it to be a copy of the data, not a reference.
That way when we copy it back in the last line of code (
$libraries = $original_libraries
) we are actually putting the original variable back, not something that got modified in the meantime when drupal_render_page() was called.Comment #14
sunI didn't know that Overlay contains wonky code like that.
That said, the patch could use some inline comments that explain the WTF that's happening there.
Comment #15
David_Rothstein CreditAttribution: David_Rothstein commentedThere are already some existing inline comments about this (not visible in the patch file, but they appear right above it in the function):
Does that work?
Comment #16
sunAh, sorry, yes that works. Also, this is merely a continuation of the existing lines for JS/CSS for libraries, so this is ready to fly.
Comment #17
webchickCommitted to 8.x and 7.x. Thanks!
Comment #18
aspilicious CreditAttribution: aspilicious commentedRemoving tags (needs backport to D7 queue cleanup)
Comment #20
TelFiRE CreditAttribution: TelFiRE commentedIs this supposed to be fixed in 7.14? I'm still getting it.
Comment #21
tim.plunkettThis was committed to D7 here: http://drupalcode.org/project/drupal.git/commit/62b52c8
Fixing tags and version.