Whenever the cancel button is pressed on a box edit form, I get a popup with the following information:
An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /admin/structure/block/manage/boxes/featured_donor_homepage/configure?destination=welcome&render=overlay
StatusText: OK
ResponseText: @import url("system/system.base.css");
@import url("system/system.menus.css");
@import url("system/system.messages.css");
@import url("system/system.theme.css");
Regards,
Nielsonm
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 1417162-cancel-button-causes-ajax-error-5.patch | 1.41 KB | tirdadc |
| #3 | 1417162-cancel-button-causes-ajax-error-3.patch | 1.41 KB | tirdadc |
Comments
Comment #1
tirdadc commentedThis only seems to happen when you're editing the box from /admin/structure/block/manage/boxes/box-[ID]/configure, not directly inline.
Comment #2
tirdadc commentedComment #3
tirdadc commentedAfter trying out older versions, it seems this problem has been around since the Cancel button was introduced. I've got a quick patch that alters the behavior on the back-end side when creating/editing boxes, while leaving the AJAX / inline version intact. Can you please test it out against a 7.x dev checkout? Seems to be working fine but confirmation is welcome.
Comment #4
nielsonm commentedThe error no longer shows up, which is a big win. I kind of expected the cancel button to close the overlay. On my setup, it redirects to /admin/structure/block. Thanks!
Comment #5
tirdadc commentedThis variant calls overlay_close_dialog() with no arguments if the overlay module is enabled, but it ultimately behaves the same way even with that (it just goes back to /admin/structure/block). Most edit forms actually no longer have an explicit 'Cancel' button other than the 'X' to the top-right side with the overlay. This seems like the standard behavior so I'm going ahead with rolling this in.
Thanks for testing it out!
Comment #6
tirdadc commented