Skip to main content

Search and Top Navigation

#9572 closed bug (notabug)

Opened September 25, 2013 01:34PM UTC

Closed September 25, 2013 02:33PM UTC

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:


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.

Attachments (0)
Change History (6)

Changed September 25, 2013 01:40PM UTC by paftek38 comment:1

Here is a test case:

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.

Changed September 25, 2013 01:45PM UTC by scottgonzalez comment:2

owner: → paftek38
status: newpending
summary: Dialog: call to _moveToTop() too aggressiveDialog: 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.

Changed September 25, 2013 02:02PM UTC by paftek38 comment:3

status: pendingnew

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.

Changed September 25, 2013 02:05PM UTC by scottgonzalez comment:4

status: newpending

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?

Changed September 25, 2013 02:18PM UTC by paftek38 comment:5

status: pendingnew

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?

Changed September 25, 2013 02:33PM UTC by scottgonzalez comment:6

resolution: → notabug
status: newclosed

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.