Opened 9 years ago
Closed 9 years ago
#9572 closed bug (notabug)
Dialog: Mousedown should not change focus if focus is already contained in dialog
Reported by: | paftek38 | Owned by: | paftek38 |
---|---|---|---|
Priority: | minor | Milestone: | none |
Component: | ui.dialog | Version: | 1.10.3 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
Hi,
I propose a slight modification in the "mousedown" handler of the element "uiDialog".
if ( this._moveToTop( event ) ) { ... }
should be
if ( this._allowInteraction( event ) && this._moveToTop( event ) ) { ... }
I have a custom widget in my dialog who open an .ui-front dropdown, and when it is focused I do not want that ui.dialog steals the focus and call _moveToTop().
Thanks for your work.
Change History (6)
comment:1 Changed 9 years ago by
comment:2 Changed 9 years ago by
Owner: | set to paftek38 |
---|---|
Status: | new → pending |
Summary: | Dialog: call to _moveToTop() too aggressive → Dialog: Mousedown should not change focus if focus is already contained in dialog |
The idea sounds correct, but I'm not sure about the proposed fix. We should probably just check if focus is in the dialog.
I'm not sure what you're trying to show with that test case; both dialogs seem to behave exactly the same.
comment:3 Changed 9 years ago by
Status: | pending → new |
---|
The test case is indeed not obvious :)
You have to click in the "Dialog 1.10.3 " input, then click elsewhere in this dialog, then click again in the input. The dropdown will be displayed behind the dialog.
comment:4 Changed 9 years ago by
Status: | new → pending |
---|
Well, to be fair, if you let .ui-front
work properly, there is no problem. So either your original description isn't correct or you're actually referring to something that's not properly using .ui-front
. Why are you appending the autocomplete menu to the body in that example? Is it to simulate a non-.ui-front
situation?
comment:5 Changed 9 years ago by
Status: | pending → new |
---|
To be fair too, I have just seen what the autocomplete's appendTo option do, and if I do the same in my custom widget it solves the problem (appending in the closest "ui-front" instead of "body")...
Sorry for taking your time.
But maybe the fix your were proposing (just check if focus is in the dialog) may be usefull in other situations?
comment:6 Changed 9 years ago by
Resolution: | → notabug |
---|---|
Status: | new → closed |
I'm not sure that there is a real problem. It sounded like there may be one, with hacked in support for elements outside of the dialog. But if the element is outside the dialog, then we won't get the mousedown, so I don't think there actually is a problem.
I'm going to close this, but if anyone is actually having a problem with this, we can look into it more.
Here is a test case: http://jsbin.com/AKUyIFA/3/
It was easier to patch _moveToTop() than the "mousedown" handler in my app to solve this bug. I did the same in my test case.