Search and Top Navigation
#6911 closed bug (notabug)
Opened January 29, 2011 10:26AM UTC
Closed January 30, 2011 03:13AM UTC
autocomplete on a contenteditable div
Reported by: | hm2k | Owned by: | hm2k |
---|---|---|---|
Priority: | minor | Milestone: | 1.9.0 |
Component: | ui.autocomplete | Version: | 1.8.8 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
Although how to make jquery autocomplete to work for a contenteditable DIV instead of just INPUT, TEXTAREA fields has already been discussed and a workaround solution has come out of it, it is not a perfect solution.
I also came across a problem using this method and trying to use the date picker: http://jsfiddle.net/xvnaA/
It appears you can't have both.
So, perhaps Steve Jiang's solution of changing the autocomplete search method to accommodate contenteditable is the way to go.
What we are aiming for here is native support for autocomplete on a contenteditable div element.
Attachments (0)
Change History (3)
Changed January 29, 2011 02:23PM UTC by comment:1
owner: | → hm2k |
---|---|
status: | new → pending |
Changed January 29, 2011 03:01PM UTC by comment:2
_comment0: | I would class unexpected behaviour as a bug. \ \ IE: I would expect autocomplete to work on a contenteditable div element. → 1296313410644837 |
---|---|
_comment1: | I would class unexpected behaviour as a bug. \ \ IE: I would expect autocomplete to work on a contenteditable div element. \ \ The bug is that, although it can (with a workaround), it conflicts with other behaviour such as datepicker. → 1296313478530418 |
_comment2: | I would class unexpected behaviour as a bug. \ \ IE: I would expect autocomplete to work on a contenteditable div element. \ \ The bug is that, although it can (with a workaround), it conflicts with other behaviour such as datepicker. \ \ A suitable solution would be to have native support for autocomplete on contenteditable div elements and it not conflict with anything else. → 1296313539978980 |
status: | pending → new |
I would class unexpected behaviour as a bug.
IE: I would expect autocomplete to work on a contenteditable div element.
The bug is that, although it can (with a workaround), it conflicts with other behaviour such as datepicker.
A suitable solution would be to have native support for autocomplete on contenteditable div elements and it not conflict with anything else.
I would say the issue is a bug, but the solution is a feature.
Changed January 30, 2011 03:13AM UTC by comment:3
resolution: | → invalid |
---|---|
status: | new → closed |
Umm...the $.fn.val = $.fn.html
solution was a joke. Doing that will break almost every single page that uses jQuery. The forum post even has descriptions of how this would really need to be done.
I'm closing this as invalid since autocomplete wasn't intended to work with contenteditable and the overview section of the docs specifically say that the plugin is to be used on an input. I've created a proper feature ticket: #6914.
This isn't a bug. Perhaps you want to meant to file this as a feature?