Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#17222 closed defect (wontfix)

[regression] TextBox: can't focus draggable TextBox with placeholder

Reported by: ben hockey Owned by:
Priority: blocker Milestone: 1.9.1
Component: Dijit Version: 1.9.0
Keywords: Cc:
Blocked By: Blocking:


r30957 introduced a regression where widgets can no longer be made moveable and be focused with a mouse.

this is because the dojo/dnd/Moveable code has an event listener for mousedown that calls e.preventDefault() and e.stopPropagation() and r30957 changed dijit's focus manager to listen to focus events as they bubble.

i've made an example at where you can see that in 1.8.3 a moveable widget could be focused (click the widget, the placeholder goes away and you can enter a value) and then if you switch the script tag for dojo to point to 1.9.0 then you can no longer focus the widget.

Change History (6)

comment:1 Changed 9 years ago by ben hockey

Milestone: tbd1.9.1
Priority: undecidedblocker

comment:2 Changed 9 years ago by bill

Hmm, that's strange, I didn't think that "r30957 changed dijit's focus manager to listen to focus events as they bubble", but rather that it normalized the behavior between old-IE and modern browsers. So, I'm surprised your test case worked in Dojo 1.8 on IE8. says that with attachEvent(), "Events always bubble, no capturing possibility".

comment:3 Changed 9 years ago by bill

The other thing I wonder about is what happens when it's a plain (non-widget) <input>, or it's a widget that doesn't extend _FocusMixin. Presumably neither of thos could get focus either, in any version of dojo, due to the evt.preventDefault() call in dojo/dnd/Moveable. So I wonder if dojo/dnd/Moveable should be calling evt.preventDefault() at all. I can see how the call to evt.stopPropagation() is useful for the case of nested Moveables like in test_Moveable.html.

I also wonder whether any of this is supposed to work, or if you are supposed to use a drag handle when the moveable object has things that can be clicked.

comment:4 Changed 9 years ago by bill

Summary: [regression] making a widget moveable prevents it from being focused[regression] TextBox: can't focus draggable TextBox with placeholder

I investigated this more.

First of all, this problem is only when there's a placeholder and the TextBox? is draggable. So it's really a corner case.

There are actually two separate things to consider:

  • the hint disappearing
  • the <input> getting focus

The problem you are talking about is the focus manager not getting the mousedown event, and thus TextBox?.onFocus() not getting called, and so the hint not disappearing. And indeed, on chrome and FF, that problem started in r30957.

On old-IE however, the focus manager never got the mousedown event, even in Dojo 1.8, but things still worked because it gets a focusin event. But the combination of (1) the evt.stopPropagation() in dojo/dnd/Moveable and (2) not hiding the placeholder until there's some value in the input (8da346e8fd9936549f706f0b313f47bf7f28b97f) causes things to break on IE.

I do agree in principle that it's better for dijit/focus to monitor mousedown in the capturing phase. I just don't like the disparity of using bubbling on old-IE and capture modern browsers. But I guess rolling back r30957 and then making 8da346e8fd9936549f706f0b313f47bf7f28b97f conditional for !(has("ie") <= 8) would be one way to get this to work. Not sure if it's worth it or not.

comment:5 Changed 9 years ago by ben hockey

Resolution: wontfix
Status: newclosed

wow... what an odd combination! seems like i hit the perfect storm. thanks for looking into it.

i've checked that if i add textBox.on('mousedown', function (e) { textBox.focus(); }); then the input receives focus - this at least gives me a way to work around this problem in the short term.

i know the behavior changed for placeHolder between 1.8 and 1.9 but does that really play into this focus issue? my problem is just that the input doesn't receive focus - the change in whether or not the placeHolder is displayed seems like it's working as expected.

i tried with a native input and it's consistent with what's happening in 1.9 so i guess that even though there is technically a regression, parity with the native element is reason enough to close this out.

comment:6 Changed 9 years ago by bill

OK glad there's a workaround.

I'm not sure why the placeHolder behavior change affects focus but that's what my tests show. I think it's because the placeHolder is blocking the <input> and it's dodgy to try and focus something that's hidden, but that's just a guess, and doesn't explain how the evt.preventDefault() call in dojo/dnd/Moveable.js comes into play.

Another wrinkle is that starting in 0016f4f there's another evt.preventDefault() call in TextBox?.js itself, in _setPlaceHolderAttr(), and then focus happens programmatically on a delay to fix some other issue.

Basically, the support for "fake" placeHolder events is very fragile.

Note: See TracTickets for help on using tickets.