Opened 7 years ago

Last modified 4 weeks ago

#9562 open enhancement

TextBox: support autocomplete=on

Reported by: neek 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 7 years ago by bill

  • Owner set to doughays

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 7 years ago by neek

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 7 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 7 years ago by doughays

  • Milestone changed from tbd to future

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 7 years ago by bill

  • Summary changed from dijit.form.TextBox template has hardwired autocomplete="off" to 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 5 years ago by bill

  • Component changed from Dijit to Dijit - Form

comment:7 Changed 4 years ago by voidstate

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 4 years ago by neek

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 3 years ago by doughays

  • Owner doughays deleted
  • Status changed from new to assigned

comment:10 Changed 3 years ago by doughays

  • Status changed from assigned to open

comment:11 Changed 10 months ago by dylan

  • Milestone changed from future to 1.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 4 weeks ago by dylan

  • Milestone changed from 1.13 to 1.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.