Download & Extend

Autocomplete: try to type a slash

Project:Drupal core
Version:x.y.z
Component:forms system
Category:bug report
Priority:normal
Assigned:Unassigned
Status:closed (fixed)

Issue Summary

If I type a slash (/) to a drupal autocomplate form item, I become 404 error.
Tests useing:
- Firefox 1.5 and Opera 9pre2 (linux)
- User name and taxonomy completion

I couldn't find a bug report or cvs commit message about this bug(?).

Comments

#1

Most likely this is the Apache %2F bug which is worked around in core. A similar fix such as drupal_urlencode() would be needed for autocomplete.js.

#2

Version:4.7.0-beta4» x.y.z

Cannot reproduce in CVS HEAD. Can somebody confirm this is fixed? If yes, this can be closed.

#3

Priority:minor» normal

I still experience this bug with 4.7.2 and I consider it to be rather important for some of the data I'm using.

#4

Found this problem using ecommerce 4.7 file.module in 4.7.2
http://urbits.com/_media/some_error.gif

#5

Status:active» closed (won't fix)

Marked "won't fix" by killes in this thread.
http://drupal.org/node/7930

So I'll do the same here.

#6

Version:x.y.z» 4.7.2
Component:other» forms system
Status:closed (won't fix)» needs review

Sorry, a "won't fix" from 2004 doesn't address how critical this is to this years autocomplete.

Here's a patch (much simpler than the other proposed workaround) that just causes the AJAX requests to be made with ?q= notation rather than as a clean URL.
This is technically more correct than relying on mod_rewrite to do everything for us anyway.

Where my errors were:

"GET /drupal_4_7/filebrowser/autocomplete_directory/imported%2F HTTP/1.1" 404

(404) I now can use:
"GET /drupal_4_7/?q=filebrowser/autocomplete_directory/imported%2F HTTP/1.1" 200

and things work again.

The change looks like this in the code of theme_textfield()

<?php
    $extra
'<input class="autocomplete" type="hidden" id="'. $element['#id'] .'-autocomplete" value="'. check_url(url('','q='.$element['#autocomplete_path'], NULL, TRUE)) .'" disabled="disabled" />';
?>

Attached patch is against 4.7.2. It appears problem persists in todays HEAD/CVS.

.dan.

AttachmentSizeStatusTest resultOperations
avoid_autocomplete_escaping_errors.patch.txt1.25 KBIgnored: Check issue status.NoneNone

#7

Version:4.7.2» x.y.z
Status:needs review» needs work

moving to cvs to increase exposure. The solution seems to be ok to me, the patch needs some coding style love.

#8

Fair call, I guess, but meaning what?
Drop the explanatory comments, and I can't see the stylistic difference between the old and new syntax & layout. It only juggles the parameters to a function. Yeh it's an ugly big line, would it be clearer in two?
I'd be happy to accede, but I'm not sure how...
.dan.

#9

Status:needs work» needs review

Using a clean URL for autocomplete is not a very clean fix. We should just mirror all the code in drupal_urlencode() to JS, work around all the Apache / mod_rewrite bugs (/, &, #) that way.

Better patch attached.

AttachmentSizeStatusTest resultOperations
encode.patch2.18 KBIgnored: Check issue status.NoneNone

#10

that is 'using a non-clean URL' of course...

#11

Status:needs review» needs work

I'm getting a
warning: Missing argument 1 for user_autocomplete() in /home/drumm/drupal/drupal/C-HEAD/modules/user/user.module on line 2365.

#12

Status:needs work» fixed

Well, slashes don't actually work because they are indistinguishable from menu path slashes, and user_autocomplete() fails. I fixed that bug and merged this into the jQuery patch, as it changes all that code around anyway.

#13

Status:fixed» closed (fixed)
nobody click here