The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Steps to reproduce - in case you can ...
- Do drush cr, then refresh the page with IPE
- Click on manage content
- Click any plugin (I usually start with search form) - configure form shows up, you can add the block
- Click any other plugin now, the spinner keeps showing, no configure form anymore - but there are no errors whatsoever. In case you inspect the response, you'll see the #panels-ipe-block-plugin-form-wrapper id, but when inspecting the DOM, it's not there.
There's no real way to reliably reproduce this for anyone else at the moment, which is of course annoying.
My current theory is that there's racing condition between the success callback and the template rendering and/or jQuery not finding the new element fast enough because it's not added by jQuery, but with backbone.
--
Originally reported by @swentel in #2600634-52: Implement Panels In-place editor display builder in panels_ipe module:
While debugging, I see the request and there's a response coming back, but the loader doesn't get replaced and no form.
Added some debugging in Blockpicker.js
// Remove our throbber on load. ajax.options.complete = function() { if (self.$('#panels-ipe-block-plugin-form-wrapper').length > 0) { self.$('.ipe-block-picker-top .ipe-icon-loading').remove(); self.$('#panels-ipe-block-plugin-form-wrapper').hide().fadeIn(); } else { console.log('oh dear, i am not there yet :('); } };Sometimes I see the console log message, sometimes the block, but not sure exactly what goes wrong here and if it is even related to javascript/ajax. Note: usually it starts showing up again after a drush cr, and then usually the first 3/4 blocks are fine, but then suddenly, nothing again.
I think this is because we we're looking for an ID of panels-ipe-block-plugin-form-wrapper which Drupal may have substituted for a different ID if it believes the ID is already on the page. We should instead use data-drupal-selector per this change record:
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | 2636484-14.patch | 1.34 KB | phenaproxima |
| #7 | 2636484-7.patch | 700 bytes | swentel |
| #3 | 2636484-3.patch | 872 bytes | swentel |
Comments
Comment #2
swentel commentedThe data-drupal-selector theory sounded great, however, tested it, same result.
My alternative theory is that somehow the javascript acts to fast and doesn't replace the content (which contains the id wrapper) in time before the complete call kicks in. Digging further.
Comment #3
swentel commentedIt looks look my theory is right, but it's not an ajax problem, rather a frontend racing condition problem: attached is a patch which makes the configure form show up always and consistently - but it obsoletes the backbone template_plugin_form function.
I seems part of the problem is that IPE is using a mix of backbone rendering and then using jquery to find the new elements, but might be unknown to jQuery sometimes. We need some frontend guru's here :)
Comment #4
dsnopek@swentel: Can you add steps to reproduce to the issue summary? I still haven't seen this locally, and if others can't either, it'll be hard to contribute... :-/
Comment #5
swentel commentedComment #6
swentel commentedUpdate the steps I do which are always consistent, first time works, after that it's broken.
Comment #7
swentel commentedDifferent patch which still uses the template theme function and removes all my functions, while still using the template function.
Comment #8
dsnopekHm. Will that mess up the animation, though? The intention appears to be to fade out, change the HTML, then fade back in. Whereas the patch appears to be changing the HTML, fading out, and then fading back in.
Comment #9
swentel commentedYeah, the animation is indeed a little off, especially if you start paying attention to it. But it's that anonymous function I'm focusing on now :)
Comment #10
dsnopekI just tried following the steps to reproduce in the issue summary (even using the "Search form" block) and I still can't get the bug to happen for me locally. :-/
Comment #11
samuel.mortensonI also can't replicate the bug, I'm wondering if this is a browser incompatibility problem (with jQuery UI I guess?), what browser/OS are you using @swentel?
Comment #12
swentel commented@samuel.mortenson
I'm on Ubuntu 15.04 - chrome is version 47.0.2526.80 (64-bit)
Laptop is Lenovo X1 Carbon - touch enabled laptop, I've been wondering that could also interfere with it, although I won't know why, will do a test disabling in it, you never know.
Comment #13
phenaproximaI ran into this today and was reproducing it pretty consistently. @swentel's patch in #7 fixed it for me.
Comment #14
samuel.mortensonOnly moving to Needs Work as we lose the animation in the newest patch.
Comment #15
phenaproximaI did some more work on this and I think I see the issue. Here's an alternative approach -- @swentel's will work just fine, but I think this patch illustrates the nature of the problem a little better. If the Ajax request is completed before the fade-out, the template_plugin_form may not have been rendered yet, which will cause the insert command to fail and the form to never appear.
Comment #17
samuel.mortensonAlthough I can't replicate the original error, the code makes sense and it's clear that the race condition was caused by the animation. Fixed + committed. Thanks all!
Comment #18
swentel commentedGlad someone else had the problem too :)
And this fixes it indeed nicely, great work!
Comment #19
dsnopekWoohoo! Thanks @phenaproxima and @samuel.mortenson for figuring this out!