Opened 13 years ago

Last modified 5 years ago

#9562 open enhancement

TextBox: support autocomplete=on

Reported by: Nick Fenwick Owned by:
Priority: low Milestone: 1.15
Component: Dijit - Form Version: 1.3.1
Keywords: textbox, autocomplete Cc:
Blocked By: Blocking:


TextBox? template says:


This makes it impossible to set autocomplete="on" on creation, one must workaround after creation, e.g.:

	dojo.attr(dijit.byId('name').textbox, "autocomplete", "on");

Would we accept a patch that adds an optional 'autocomplete' argument to the TextBox?, allowing autocomplete to be set on creation? It would default to 'off' of course.

With it defaulting to the current hardwired value, I don't see how it would degrade other widgets that use it.

Previously discussed in

Change History (12)

comment:1 Changed 13 years ago by bill

Owner: set to Douglas Hays

Hmm, I'm not sure, it seems like this would interfere with all the MappedTextBox based widgets (such as NumberTextBox) which have a displayed value and an actual value that gets submitted (which is hidden). If the auto-complete operated on the displayed value then the hidden value would get out of sync.

Also, I'm not sure if auto-complete would even work, given that template replaces a single <input> in the markup with multiple <input> nodes... that kind of thing can confuse a browser's auto-complete system, perhaps writing the auto-complete value to a previous node (like writing your address in the name field).

comment:2 Changed 13 years ago by Nick Fenwick

I would hope any existing widgets would be unaffected, as they wouldn't pass an autocomplete=on and therefore TextBox? would default to the old behaviour.

I'm only suggesting a change to the TextBox? (and thus ValidationTextBox?) to allow their <input> field to set autocomplete=on. Without the above workaround, these dijits cannot provide browser autocomplete for the login form username field, which seems a common enough requirement.

bill: I also didn't think there were multiple <input> nodes, see dijit/form/templates/TextBox.js, .../ValidationTextBox?.html. ComboBox?.html has its own <input> tag in its template, and I'm not suggesting we change that. Can you name a specific widget that might cause problems?

Anyway, I'm just sticking a foot in the water to see what you guys think. I've only been using dojo a few months, and find it hard to believe this issue hasn't come up before, I feel sure there must be some prior issues I don't know about, but searching Trac didn't show anything.

In some initial testing, I'm finding there are some problems setting focus to my altered TextBox? input field, but I can't test further right now due to some platform issues on my side. I'll update this bug when I can with some more definite results.

comment:3 Changed 13 years ago by bill

I agree that there wouldn't be problems w/TextBox so maybe it's worth doing.

There would be issues w/FilteringSelect, NumberSpinner, DateTextBox, etc. The code you need to look at is the MappedTextBox mixin... the second <input> is generated programatically, not part of the template.

comment:4 Changed 12 years ago by Douglas Hays

Milestone: tbdfuture

The reason that autoComplete is off is because it allows browsers (at least Firefox) to modify values and bypass the onChange handling. The result is that the form can be submitted with the ENTER key and user handlers have not yet been notified. I'll leave this open in hopes someone will append a patch.

comment:5 Changed 12 years ago by bill

Summary: dijit.form.TextBox template has hardwired autocomplete="off"TextBox: support autocomplete=on

Oh, I guess you mean that when autoComplete is turned on, the browser will sometimes auto-complete the value (filling in remaining letters) but the onChange() handler won't be called with that final value.

I don't have any ideas about how to work around that (other than documenting it).

comment:6 Changed 11 years ago by bill

Component: DijitDijit - Form

comment:7 Changed 9 years ago by Fergus Hadley

I wish there was some way of voting on issues in Trac. I use Dojo for most of my projects and this issue comes up nearly every time I ise a dijit.form.TextBox? as part of a login form or address/payment capturing form. This single issue means I spend time defending Dojo to clients and less technical designers, salespeople and managers. Is there no workaround at all?

comment:8 Changed 9 years ago by Nick Fenwick

voidstate - it seems there are two main issues.

  1. onChange isn't fired when the browser autocompletes a text box
  2. a dijit/form/TextBox is not recognised by the browser as an autocompletable field, because it's created dynamically after the page loads (even if instantiated from a <input data-dojo-type="dijit/form/TextBox">, it's torn down and replaced from a template). You can get around this by serving an <input> with the initial page content but have it hidden (e.g. display:'none') and moving it to the relevant place on the page when your TextBox? is instantiated, though this would involve quite a serious hack of TextBox?.

While you may be able to live with point 1/, point 2/ is quite a headache and not something a javascript toolkit can solve out of the box. It's going to require some work in concert with the server to get a suitable input field in the HTML content served to the browser.

Have you tried forcing autocomplete="on" and run into the problem that the browser doesn't properly remember password values? Do you have any feedback that might help? I found that to be pretty insurmountable. Incidentally, you also need to use traditional form submission, you can't use ajax or dojo/request to post a login form and expect the browser to remember your passwords.

On top of that, my solution that serves hidden fields with the initial page load (I served an entire <form> login form) and moves them to a relevant location when required (during a dijit's buildRendering, for example) causes password remembering tools such as LastPass? to pop up auto-fill notifications even when the fields were invisible. This means your site will cause ugly and meaningless UI interactions while those fields aren't visible e.g. on initial page load. I've ended up falling back to an old fashioned static login page with traditional form submit.

comment:9 Changed 8 years ago by Douglas Hays

Owner: Douglas Hays deleted
Status: newassigned

comment:10 Changed 8 years ago by Douglas Hays

Status: assignedopen

comment:11 Changed 6 years ago by dylan

Milestone: future1.12

we really probably should have addressed this years ago. Marking as a candidate for 1.12 if we can achieve it.

comment:12 Changed 5 years ago by dylan

Milestone: 1.131.15

Ticket planning... move current 1.13 tickets out to 1.15 to make it easier to move tickets into the 1.13 milestone.

Note: See TracTickets for help on using tickets.