As first pointed out in #229825: backport "$_COOKIE['has_js'] must die" patch to 7.x, the Batch API falls back to using a meta-refresh tag when Javascript is disabled.
Some browsers (lynx) do not support this tag at all, and some (Opera?) allow it to be disabled.
The Batch API, and any other code that uses a meta refresh element, must print a visible message on the page that informs the user they are waiting to be redirected, and provide a link to manually follow the redirect.
This is common fallback behavior; see SourceForge download links and the 404 message at http://www.wikipedia.org/Article for two examples.
Comments
Comment #1
keith.smith CreditAttribution: keith.smith commentedThis may be a duplicate, or at least a closely-related cousin, of http://drupal.org/node/204374.
Comment #2
Robin Monks CreditAttribution: Robin Monks commentedIn reply to #1:
I believe this bug is better suited to handle the issue, since http://drupal.org/node/204374 is much "vaguer".
Robin
Comment #3
cburschkaNote: The proposed fix of adding a visible link will fix the issue for text-only browsers, but will of course not work for non-interactive user-agents (such as cron).
We will need to rethink this problem eventually, even if we do it only in D7. The batch API is a fine piece of work, but it relies completely on interactive interfaces, which is not always useful. Historically, batch jobs are processed non-interactively on most systems. That makes this problem somewhat ironic.
Comment #4
Chris Johnson CreditAttribution: Chris Johnson commentedPerhaps this comment does not add much value to the conversation, but it just struck me: how can it be called a batch API if it requires interactive usage? The two terms are essentially exclusive opposites by definition.
Comment #5
Robin Monks CreditAttribution: Robin Monks commentedYeah, yeah, I know.
So shoot me ;)
Robin
Comment #6
cburschkaHow exactly is this a documentation issue? User interface text, at best, but documentation?
Comment #7
Robin Monks CreditAttribution: Robin Monks commentedWeird, I didn't change that select :-/
Robin
Comment #8
mikeytown2 CreditAttribution: mikeytown2 commentedThis is an example of code that calls it's self until it is done. Only works on linux boxes & you need to set it up according to your server configuration. If you could detect the location of the php interpreter on the system, then that would make life simpler.
http://drupal.org/node/363077#comment-1790536
It runs completely independent of Drupal, but in the future I will have it use the Drupal DB to keep track of it's self instead of a temp file.
Comment #9
mikeytown2 CreditAttribution: mikeytown2 commentedmade said code work on all systems now... there's enough there to make this work now.
http://drupal.org/node/363077#comment-1834282
Comment #10
nod_Comment #11
mikeytown2 CreditAttribution: mikeytown2 commentedThis issue can be fixed if this issue gets in #1447736: Adopt Guzzle library to replace drupal_http_request()
Comment #12
effulgentsia CreditAttribution: effulgentsia commentedMy read of this issue is that the server-side portion of BatchAPI should be fixed to output a link for interactive browsers. Is that correct? If so, I don't see how Guzzle is related. Or, is this issue about making simpletest or some other non-interactive core http client support meta refresh? In which case, yes, a better http client library would help, but if that's what this issue is about, can the title and summary be updated accordingly?
Comment #13
mikeytown2 CreditAttribution: mikeytown2 commentedBatch API uses the browser to start up PHP multiple times. Guzzle can do a non blocking request to it's self; this allows for the batch to be done without a browser window by emulating what a browser would normally do (request the page again once processing is done for that run). Guzzle allows us to redefine what we think of when we say Batch API. Currently we think it requires a browser window to always be open in order to preform the batch operation. With Guzzle we could fire off a batch operation and have a currently running jobs dashboard, allowing one to see ALL currently running batch operations and things like that. All of this requires a complex HTTP client like Guzzle.
Comment #14
nod_Guzzle is in so what's the status of this?
Comment #23
catchThis is closely related to #1189464: Add an 'instant' queue runner although the proposed implementation is different. In both cases it's trying to move some batch operations to non-blocking.