Opened 10 years ago

Closed 10 years ago

#10041 closed defect (fixed)

Dialog: can click through to select underneath Dialog (IE8)

Reported by: bill Owned by: bill
Priority: high Milestone: 1.4
Component: Dijit Version: 1.3.2
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

Open test_Dialog.html in IE8 and size browser window such that the DateTextBox in the first dialog (from the "Show Dialog" button) overlaps the <select> in the middle of the screen.

By clicking in position of the select, it will actually open and bleed through the dialog:

No image "bleedingSelectCropped.png" attached to Ticket #10041

I'm also seeing intermittent errors on Dialog_mouse.html where the Calendar drop down doesn't open. I think it's caused by this problem, although not sure.

Attachments (3)

bleedingSelectCropped.PNG (14.5 KB) - added by bill 10 years ago.
screenshot
bleedingSelectCropped.2.PNG (14.5 KB) - added by bill 10 years ago.
screenshot
bgIframe_10041.patch (405 bytes) - added by Sam Foster 10 years ago.
[CLA] [PATCH] fix to dijit.BackgroundIframe? to prevent that flash of solid color as the iframe is inserted

Download all attachments as: .zip

Change History (17)

comment:1 Changed 10 years ago by bill

Description: modified (diff)

Changed 10 years ago by bill

Attachment: bleedingSelectCropped.PNG added

screenshot

Changed 10 years ago by bill

Attachment: bleedingSelectCropped.2.PNG added

screenshot

comment:2 Changed 10 years ago by bill

Description: modified (diff)

comment:3 Changed 10 years ago by bill

Milestone: tbd1.4
Owner: set to bill
Status: newassigned
Summary: Dialog: can click through to select (IE8)Dialog: can click through to select underneath Dialog (IE8)

comment:4 Changed 10 years ago by bill

Resolution: fixed
Status: assignedclosed

(In [20473]) Since IE8 needs a background iframe in addition to IE6 (although the problem is more subtle than on IE6, see #10041), and since when there's a PDF/applet on the page then all IE's + all firefox's need an iframe, expand the cases where we do the iframe. Fixes #10041, refs #9805 !strict. Also did a few lines of style cleanup.

comment:5 Changed 10 years ago by Nathan Toone

Resolution: fixed
Status: closedreopened

A side-effect of this last fix is that the "fade" for the background is no longer smooth....it goes to 100% opacity and wipes out the entire background (on FF). This can be seen by opening a dialog on the test_Dialog.html page, and watching the background as it fades in. Before [20473], it would fade in smoothly, after [20473], it would not.

comment:6 Changed 10 years ago by bill

In the old days the underlay faded in, but that was changed a long time ago. It comes in instantly long before [20473]. Here's the code in Dialog.js that shows the underlay instantly and then shows the dialog:

this._fadeIn = dojo.fadeIn({
	node: node,
	duration: this.duration,
	beforeBegin: dojo.hitch(this, function(){
		...
		underlay.show();
	}),
	...
 });

The dialog fades in but the underlay comes in instantly.

Not sure what you are seeing?

comment:7 Changed 10 years ago by Nathan Toone

Sorry - I mis-spoke. What I meant is that when the *DIALOG* begins fading in, the *UNDERLAY* is at 100% opacity. It gets updated to its proper opacity shortly thereafter (500ms later or so).

This is on FF only. It might be easier to see in the test case if you change the color of the underlay - since it is a bit difficult to see the difference in opacity of white underlay on (mainly) white webpage.

comment:8 Changed 10 years ago by Nathan Toone

More specifically, I'm only seeing it on FF3.5...(FF3 does not have this problem)

comment:9 Changed 10 years ago by bill

The effect is that all the text on the page disappears for a split second and then reappears.

Are you seeing the problem on FF3.5/win, or just FF3.5/mac? I'm just seeing it on the mac. If it's only on the mac I'll just disable the iframe on the mac, as it isn't helping there anyway (FF3.5/mac is really broken and there's no known way to make dialogs appear on top of applets, even with an iframe)

I tried moving the iframe from the underlay to the Dialog itself but that has other issues on FF, namely that (reminiscent of IE6's problem with selects) the underlay doesn't block out the applet.

comment:10 Changed 10 years ago by Nathan Toone

I'm seeing the same thing in FF3.5/win (but not FF3.0 on mac or win).

comment:11 Changed 10 years ago by bill

Oh, I see, on FF3.5/win it only happens the first time the underlay is shown.

comment:12 Changed 10 years ago by Nathan Toone

I only see it the first time the underlay is shown on mac as well...

Changed 10 years ago by Sam Foster

Attachment: bgIframe_10041.patch added

[CLA] [PATCH] fix to dijit.BackgroundIframe? to prevent that flash of solid color as the iframe is inserted

comment:13 Changed 10 years ago by Sam Foster

bgIframe_10041.patch amends dijit/_base/popup.js to set opacity on the iframe element before it is appended to the BackgroundIframe?'s node. This is to fix the flash of solid grey you see in FF3.5 when showing a Dialog.

I went around some variations, including setting opacity on

.dijitDialogUnderlayWrapper iframe {
	-moz-opacity: 0.1;
}

but that didnt work. Also, whatever we do needs to be done there, right before the iframe is appended, no sooner or later apparently. There may be other properties we can set to have the same effect, but this was what worked for me.

comment:14 Changed 10 years ago by bill

Resolution: fixed
Status: reopenedclosed

(In [20577]) Workaround flashing problem on FF3.5 when dialog/menu/etc. is first shown. Thanks Sam. Fixes #10041, #10111 !strict.

Note: See TracTickets for help on using tickets.