I noticed this when installing my node access module (http://drupal.org/node/205792), but yched pointed me to a more mainstream test:

go to admin/content/node, select *more than 10 nodes* and 'publish' them (doesn't matter if they're already published).

If I try this, then I get to batch?op=start&id=123, title "Processing", and sit there forever. If I click the [Go] or [Refresh] buttons, then the process continues: I briefly see the animated progress bar (afaik the animation proves that JS is running), and I'm finally redirected back to admin/content/node, without any further user intervention.

I expected this to proceed automatically and to provide a fall-back mechanism of the sort "If your browser does not proceed within 5 seconds, click here to continue." My browser does redirect though, I've verified that on http://www.pageresource.com/html/refex1.htm.

This is on WinXP with FF 2.0.0.11 as well as with IE6SP2. FF is loaded with all sorts of extensions, but IE is plain, and I've added my test site (local Apache/2.0.59 (Win32) SVN/1.4.0 PHP/5.1.6 DAV/2) to the trusted zone. I also have ZoneAlarm installed, which may be interfering in some way, but

1. there should be a fallback mechanism in any case, and

2. I don't know where to look -- what is it that should automate that step which isn't proceeding? Is it JS? Meta Refresh? HTTP Redirect? What is different in that initial step vs. the final redirect back to admin/content/node?

3. Is there a batch test that can be triggered with a GET rather than a POST? I have a tool that let's me GET a url and shows me every byte retrieved, but unfortunately it doesn't work with POST.

Comments

yched’s picture

yched commented

Could you use Firebug to :
- check if there are JS errors on the page where the redirection fails to happen ?
- check if any AHAH request is emitted (under Net / XHR Firebug tabs), and if yes, what's the response.

Also, do you happen to have a live site where this is visible (possibly send me url and login through my contact form on drupal.org) ?

JirkaRybka’s picture

JirkaRybka commented

I also got stuck in a similar way on update.php run 5.x->6.x, where it turned out to be outdated js in browser cache. Not sure whether this is related, but linking anyway: http://drupal.org/node/199946 That problem is temporarily solved by hitting reload before the operation.

salvis’s picture

salvis
he/his
commented

The problem seems to be on my end: progress.js is somehow truncated, apparently by ZoneAlarm. Firebug gives me the following errors:

missing ) after condition                                                 progress.js (line 32)
[Break on this error] if (percentage >= 0 && percentage

Drupal.progressBar is not a constructor                                   batch.js (line 33)
var progress = new Drupal.progressBar('updateprogress', updateCallback, "POS...

After turning off ZoneAlarm (Security Suite 7.0.462.000) it works.

Oddly enough, Firebug shows the complete untruncated file, but apparently FF only gets part of it.

(I sent you url and login earlier tonight, but this is not needed anymore, so I've removed the account.)

P.S. "hitting reload before the operation" hasn't made any difference for me.

yched’s picture

yched commented
Status: Active » Closed (won't fix)

OK - meawhile, I did check your live site and saw batches running fine :-)

Setting as 'won't fix', then; Firewalls blocking js execution is nothing we can fix.
Thanks for investigating :-)

salvis’s picture

salvis
he/his
commented

(you just beat me to reply)

Hitting reload on the admin/content/node page doesn't help, because that page doesn't include progress.js. However, clearing the cache completely (with Web Developer) makes it work on the next request. However, after being redirected back to admin/content/node, I get

missing ) after condition                                                     tableheader.js (line 67)
[Break on this error] if (offset > 0 && offset

Somehow, the browser gets bad data into its cache. Interestingly, IE6 behaves in exactly the same way.

I don't think it's a case of "Firewalls blocking js execution" but rather trashing data, but this doesn't make a difference, I guess...