update.php hangs

Confirming this - Update.php does not work in opera 8.51.

Note that the update.php script does also work in firefox 1.5

Same problem with Opera 9.0P1.

I can also confirm that this problem was introduced by the new update.php - Drupal 4.6.0 update.php works perfectly on Opera 8.51.

This is an issue for UnConeD to look at. He wrote most of the JS.

I think the solution is to turn off Drupal's JS for Opera. It should automatically fall back to the method involving meta-refreshes.

Seems Opera does not perform XMLHttpRequest POST when the data is undefined or null. Patch attached, tested on Opera 8.51.

Oh and I also included a slight code fix for update.php to remove a foreach warning.

Looks good to me.

Steven and Drumm: Thanks for looking into this. I'll see about getting Opera fixed.

Works with Opera now. Tested with Opera 9.0P1+.

Filed as Opera bug 190245. The WHATWG WebApps 1.0 spec. does not define what should happen if send() is null or undefined[1]. I've contacted the spec. author for clarification.

[1] http://www.whatwg.org/specs/web-apps/current-work/#scripted-http

What does it mean when an object is undefined or null? Sorry, I'm not too familiar with the spec. Can't we ensure that object is always properly defined, rather than putting a browser hack in? I'm OK with this patch but I wanted to double-check.

Dries: It's not that the variable is undefined, per se, but that there's no data sent when the script reaches the send() function. I'm not sure why that happens, though.

POST doesn't seem to be a requirement in this case, and changing it to a GET works just fine (tested in FF and Opera 8.01). Attached a patch.

Note: I avoided touching progress.js, but if an empty HTTPPost won't work then perhaps it's best to enforce a GET request to find the progress?

Committed to HEAD. Thanks.

This patch was completely bogus, because the JS codepath was broken. The 'has js' form field no longer has an ID, which means it can not be found anymore. Furthermore, update.php explicitly checks for 'POST', so it would not have worked.

Can we test this stuff properly next time?

Here's a patch:

• Restores Javascript functionality. The javascript trigger (input type="hidden") had lost its id after patch #40486, so the javascript code couldn't find it anymore. I added the id manually.*
• Passes empty string rather than type 'undefined' to HTTPPost() from progress.js to work around the Opera bug. I also added a comment to HTTPPost to explain this quirk.

I can't immediately give a clear reason why POST rather than GET is used for the Ajax progress monitoring/updating request, but Neil did add this explicitly, so there must be a good reason. There is even a check so that GET requests don't work at all. I'm guessing it helps to avoid caching-issues on the Apache or proxy/client side (not Drupal caching). Using POST also makes more sense because each requests performs new updates rather than just fetching status passively.

Patch tested on Safari, Firefox and Opera (all on OS X). I can't test IE because my wintel box blew up, but it is unlikely that this change would affect it.

*: You could argue that the Ajax codepath is unnecessary because the meta-refresh version works equally well. But, especially when updating a remote server, the UI in the meta-refresh version will flicker because it reloads every time. The Ajax version only adjusts the progressbar display so it is a lot nicer.

Updating changes data, so it should be POST.

Technical requirements (meta-refresh sucking) require the non-JS version to use GET. POST isn't technically required, but is the more correct way to do things when possible.

No need to send a blank string, the problem is more obscure than that - we should offer the HTTP method in lowercase apparently.

This minor tweak lets me POST blank data in Opera 8.01.

I'm pretty sure a lower case 'post' won't work at all in Opera 8.01. That was one of the bugs fixed in Opera 8.02.

Steven: I'd prefer if you said it's a work-around for Opera 8. We'll have this fixed in Opera 9.

I just ran into something that fits this description on firefox (1.0.6 linux) while updating to 4.7.0-test2

Steven's latest patch is working here again.

Patch doesn't apply.

Rerolled patch. It looks like the problem was a conflicting CVS ID in drupal.js.

Committed to HEAD. Thanks.