Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#17154 closed defect (fixed)

[regression] Unable to edit dijit.form.TextBox when it is placed inside a dijit.Toolbar

Reported by: lbus Owned by: bill
Priority: high Milestone: 1.9.1
Component: Dijit Version: 1.9.0
Keywords: Cc:
Blocked By: Blocking:

Description

Textbox is not editable when it is placed inside a toolbar. Check attached test with a toolbar with a non editable textbox and one text box outside toolbar which works properly.

Attachments (1)

test_ToolBarTextBox.html (1.5 KB) - added by lbus 6 years ago.
Test case

Download all attachments as: .zip

Change History (18)

Changed 6 years ago by lbus

Attachment: test_ToolBarTextBox.html added

Test case

comment:1 Changed 6 years ago by lbus

Problem does not appear with dojo/dijit version 1.8.3.

comment:2 Changed 6 years ago by bill

Milestone: tbd1.9.1
Summary: Unable to edit dijit.form.TextBox when it is placed inside a dijit.Toolbar[regression] Unable to edit dijit.form.TextBox when it is placed inside a dijit.Toolbar

I assume you are talking about problems typing, rather than just problems using the left/right arrow keys, which is a known issue reported in #16266.

Last edited 6 years ago by bill (previous) (diff)

comment:3 Changed 6 years ago by lbus

Yes, it is not possible to enter any text. Looks like keyboard events are ignored.

comment:4 Changed 6 years ago by bill

Cc: Douglas Hays added

Doug, what do you think of adding a stopPropagation() (but not preventDefault()) call in _TextBoxMixin? It would indicate that the event was handled by the TextBox, which is true for the case of printables. We probably should also call stopPropagation() for navigation keys (arrow keys and HOME/END keys), to solve #16266.

I suppose ideally keystrokes like ctrl-x should be allowed to bubble, since they don't mean anything to the TextBox but could mean something to the container. But perhaps it's good enough to just call stopPropagation() all the time.

comment:5 Changed 6 years ago by bill

PS: I suppose the ENTER key should also be allowed to bubble. It's used to submit forms. Not sure if it needs to bubble for the form to submit, but that seems safer.

comment:6 Changed 6 years ago by bill

Cc: Douglas Hays removed
Owner: changed from bill to Douglas Hays
Status: newassigned

comment:7 Changed 6 years ago by doughays-dojo <doughays@…>

Resolution: fixed
Status: assignedclosed

In 781f907f1371f6573bc0eb0b9c85d0c636d04e77/dijit:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:8 Changed 6 years ago by doughays-dojo <doughays@…>

In f788c9d8f670d92f3b5b260126cbd3e19de824a2/dijit:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:9 Changed 6 years ago by Douglas Hays

This fix allows printable keypresses and BACKSPACE to flow to the INPUT, but other editing keys (arrows/home et al) will continue to be intercepted by the ToolBar? widget. Commentary to that should continue on #16266.

comment:10 Changed 6 years ago by bill

#17270 is a duplicate of this ticket.

comment:11 Changed 5 years ago by dylan

Milestone: 1.9.1
Resolution: fixed
Status: closedreopened

This fix actually breaks a pretty common pattern with ValidationTextBox?, which is to prevent/mask invalid input.

Prior to this change, you could extend ValidationTextBox? with something like:

require([
    "dojo/_base/declare",
    "dijit/form/ValidationTextBox",
    "dojo/domReady!"
], function (declare, ValidationTextBox) {
    function isNumber(n) {
        return !isNaN(parseFloat(n)) && isFinite(n);
    }
    var InputBox = declare([ValidationTextBox], {
        buildRendering: function () {
            this.inherited(arguments);
            this.on("keypress", function (event) {
                var value = this.get("value") + event.charOrCode;
                if ((/\s/).test(event.charOrCode) || !isNumber(value)) {
                    // if value is not a number, ignore it
                    event.preventDefault();
                }
            });
        },
        validator: isNumber
    });
    new InputBox().placeAt(document.body);
});

With this change, you must use

this.on("input", function (event) {

Is this intended?

comment:12 Changed 5 years ago by dylan

Milestone: 1.10
Owner: changed from Douglas Hays to bill
Priority: undecidedhigh
Status: reopenedassigned
Version: 1.9.01.9.3

comment:13 Changed 5 years ago by bill

I suppose the stopPropagation() call (from 781f907f1371f6573bc0eb0b9c85d0c636d04e77) should happen on this.domNode rather than this.textbox.

PS: Sounds like the actual bug is more general than event.preventDefault() being broken, it's that TextBox?.on("keypress", ...) no longer works.

Last edited 5 years ago by bill (previous) (diff)

comment:14 Changed 5 years ago by bill

Resolution: fixed
Status: assignedclosed
Version: 1.9.31.9.1

I'll track that new problem in #17826. The change from this ticket also needs a test case; I will check them in together.

comment:16 Changed 5 years ago by Bill Keese <bill@…>

In 289f96b2592e3bb23a714256ab1d48bcbfaa3bce/dijit:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:15 Changed 5 years ago by Bill Keese <bill@…>

In 073c1a07a3fc26901b63bda9f1e195fdaf7e9499/dijit:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:16 Changed 5 years ago by bill

Milestone: 1.101.9.1
Version: 1.9.11.9.0
Note: See TracTickets for help on using tickets.