Image field 'Remove' button broken

Maybe introduced by upgrading to jquery 1.4.2
Don't know if it existed before...

Seems that we can't remove the image because hook_file_references() reports that the file is in use. (and Maybe it is, because we're actually use it in the node himself...) and on file.module, $element['#file']->status is been check if it's set to 1.

Setting the $force Boolean to "true" seems to make the trick (not sure if it is the best way...)

Patch attached

(Sorry, forget about last patch, here is another one)

I' pretty sure this is NOT the way to do that. but if that could help someone to track the bug.

Needs review status for bot

+++ file.module	10 Mar 2010 11:22:12 -0000
@@ -393,8 +393,9 @@ function file_managed_file_process($elem
+    ¶

empty lines should not have any spaces

145 critical left. Go review some!

I checked earlier alpha releases and it looks like this bug was introduced in version 7.0-alpha3. Alpha2 works fine.
Checking the differences between the two versions...

I did some debugging between alpha2 and alpha3. It turned out that there's no significant code change in file.module.
However I noticed that in line 258 of file.module, variable $output has different value in alpha3.
As far as I understood, it should contain a piece of HTML that is supposed to replace image field's widget when remove button is clicked. Unfortunately this has exactly the same markup as the current widget (that shows the existing image and the remove button) instead of the new image upload stuff. That's why nothing changes...seemingly.

So we need to dig deeper in order to find out why drupal_render($form) returns this false result.

This is being worked on as part of #736298: Refactor file.module to use proper button click detection, enabling FAPI to improve button click detection security

@effulgentsia Glad to hear that. Thanks :)

Even ahead of the other issue, this one appears to be fixed now. If someone discovers otherwise, please set status back to "duplicate".

Nope. Still broken, but only with JS enabled. Works fine with JS disabled. #736298: Refactor file.module to use proper button click detection, enabling FAPI to improve button click detection security fixes it, but needs a test added to keep it fixed.

#736298: Refactor file.module to use proper button click detection, enabling FAPI to improve button click detection security and #756762: AJAX should follow same rules for whether to call drupal_rebuild_form() as non-AJAX submissions both fix this bug, and each is a critical issue, but they're large patches needing thorough review and will take time to move through the process, especially with people about to be busy with DrupalCon. In the meantime, we don't want this bug getting in the way of people working with Drupal 7, so here's a small patch that fixes it. It's basically how #756762: AJAX should follow same rules for whether to call drupal_rebuild_form() as non-AJAX submissions started before becoming a more ambitious and nicer cleanup of the underlying issue. My vote is for this patch to go in without new tests added, because I want to take some time improving the AJAX test coverage in file.module as part of #736298: Refactor file.module to use proper button click detection, enabling FAPI to improve button click detection security, but won't be able to get to that probably until after DrupalCon.

Not sure whether we have time for stop-gap fixes. I'd suggest to fix it properly via the other issues/patches.

Agreed, lets fix it the right way.

problem still exists
subscribing

subscribing

The problem gone when I disabled jquery_update module.

subscribing

I'll make do with the core jQuery until 7.1!

jQuery 1.5 is not backwards compatible with jQuery 1.4, so will not be included in Drupal 7.1, or likely any version of Drupal prior to 8.0. It is the responsibility of the jQuery Update module to include JavaScript to fix breakages it introduces. For the file upload/remove breakage, that's being worked on in #1064890: Update jQuery Form to 2.64.