Ticket #4309 (closed bug: fixed)

Opened 6 years ago

Last modified 2 years ago

Opening multiple modal dialogs causes access problems to inputs

Reported by: boconnor Owned by: scott.gonzalez
Priority: blocker Milestone: 1.7.2
Component: ui.dialog Version: 1.7
Keywords: Cc:
Blocking: Blocked by:

Description

A modal dialog (Dialog A) is opened that has an <input> field. Another modal dialog (Dialog B) is opened. Modal Dialog B is closed.

It is now impossible to focus on the <input> field in Modal Dialog A.

Bug exists on all browsers.

Attachments

index.cfm Download (980 bytes) - added by boconnor 6 years ago.
Simple example of problem
index.html Download (980 bytes) - added by boconnor 6 years ago.
Simple test case
jquery-ui-dialog.patch Download (466 bytes) - added by MacAnthony 6 years ago.
patch file for jquery-ui.js version 1.7.1

Change History

Changed 6 years ago by boconnor

Simple example of problem

Changed 6 years ago by boconnor

Simple test case

comment:1 Changed 6 years ago by MacAnthony

This has something to do with the events being added to modals. If you remove the event list from line (  link to code ) it works. Of course, this also breaks other functionality. I haven't determined if it's related to when they are binded or when they are unbinded. If there are any events in there, this problem persists. I tried removing each individual one. Didn't help.

comment:2 Changed 6 years ago by MacAnthony

Removing the if expression from this code block also makes it so it works:

	destroy: function($el) {
		this.instances.splice($.inArray(this.instances, $el), 1);
        
		if (this.instances.length === 0) {
			$([document, window]).unbind('.dialog-overlay');
		}

		$el.remove();
	}

I think this would break all the overriding event binds from the original dialog box though. It looks like it should unbind all the .dialog-overlay events for the first dialog or previous dialog box if more than 2.

Changed 6 years ago by MacAnthony

patch file for jquery-ui.js version 1.7.1

comment:3 Changed 6 years ago by MacAnthony

The patch file I put in there is the current patch file we are going to use to get around this until a better solution becomes available. Hopefully it might help in coming up with a more permanent solution in the core.

comment:4 Changed 6 years ago by scott.gonzalez

  • Milestone changed from TBD to 1.8

comment:5 Changed 6 years ago by scott.gonzalez

  • Owner set to scott.gonzalez
  • Status changed from new to accepted

comment:6 Changed 6 years ago by scott.gonzalez

  • Status changed from accepted to closed
  • Resolution set to fixed

Fixed in r2431.

comment:7 Changed 5 years ago by rdworth

  • Milestone changed from 1.8 to 1.7.2

comment:8 Changed 5 years ago by sp

using 1.8rc3, the problem still happens, also for the test-case

comment:10 Changed 4 years ago by Myrlyn

I ran into this problem despite the fixes because I had another element in the page using the ui-dialog class (an older piece of the page was using jqModal, and we updated it to look like ui-dialog by just putting the class on the DIV). As a result, because this element did not have a z-index, when the line of code that checks the z-index was run, the value of z-index was "auto". This causes maxZ to be evaluated as NaN, and causes the problem described above. I was able to fix the problem by ensuring this other element had a numerical z-index.

comment:11 Changed 2 years ago by drakes

EDIT: moved to new ticket

Last edited 2 years ago by drakes (previous) (diff)
Note: See TracTickets for help on using tickets.