Opened 10 years ago

Closed 10 years ago

Last modified 9 years ago

#9805 closed defect (fixed)

Dialog: hidden behind PDF or applet

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

Description

When working with Java applets, the only way to layer DOM nodes over them is to apply a background iframe to the element. dijit.BackgroundIframe? only works for IE < 7 and Firefox < 3. There is no way to override it. I'm attaching a patch to add a djConfig property called forceBgIframe, remove the expression syntax for IE8, and set the width and height of the iframe if the browser is not IE<7. I'm also attaching a test file to show that this works.

Attachments (6)

bgiframe.diff (1.1 KB) - added by Bryan Forbes 10 years ago.
bgiframe-2.diff (1.6 KB) - added by Bryan Forbes 10 years ago.
bgiframe-3.diff (1.6 KB) - added by Bryan Forbes 10 years ago.
test_bgIframe.html (2.4 KB) - added by bill 10 years ago.
iframeSizing.png (8.4 KB) - added by bill 10 years ago.
iframe too tall on IE6
9805.2.patch (798 bytes) - added by haysmark 10 years ago.
Fixes #9805. Added back an accidentally removed dojo.config parameter. Fixed copy-paste typo.

Download all attachments as: .zip

Change History (29)

Changed 10 years ago by Bryan Forbes

Attachment: bgiframe.diff added

comment:1 Changed 10 years ago by bill

It's actually working OK on safari (probably chrome too), but I do see the problem on FF and IE8 (probably IE7 too).

About the dojo.style() call to set width and height: it's a little worrisome. The reason IE uses expressions is that the main DOMNode (the foreground of the BackgroundIframe) might change size, and then the iframe should change along with it. For example, in the case of Dialog, the user might resize the browser window. Or a TooltipDialog might contain an expanding Textarea and thus will change size as the user types. (The latter case is a bit hard to imagine though, and I'm not sure if it works properly anyway, as resizing TooltipDialog's would sometimes require repositioning, to stay within the viewport.)

BTW dojo.isIE&&dojo.isIE<8 is equivalent to dojo.isIE < 8 because on non-IE browsers dojo.isIE is undefined and undefined < 8 returns false (or maybe undefined... anyway, it isn't true).

Changed 10 years ago by Bryan Forbes

Attachment: bgiframe-2.diff added

Changed 10 years ago by Bryan Forbes

Attachment: bgiframe-3.diff added

comment:2 Changed 10 years ago by Bryan Forbes

I've attached a new patch. I've changed dojo.isIE&&dojo.isIE<8 to just dojo.isIE<8 or whatever is applicable. I've also removed the expression syntax since, according to http://developer.yahoo.net/blog/archives/2007/07/high_performanc_6.html , expressions will evaluate more often than just a resize. Often, when the mouse just moves over the page. Instead, I attach to the parent node's onresize event for IE6 and lower. When the dijit.BackgroundIframe is destroyed, I disconnect from it. For IE7 and higher, setting the iframe's style to width: 100%; height: 100% is sufficient.

One other thing I did was update the test to add some tooltips of different size to test the iframe changing size.

comment:3 Changed 10 years ago by liucougar

can we move dojo.config.forceBgIframe to the dijit.BackgroundIframe? itself? I think it makes more sense there: only if dijit.BackgroundIframe? is created for a java applet (or flash, IIRC), it should be "forced"

comment:4 Changed 10 years ago by Bryan Forbes

How do you propose doing something like that for dijit.Dialog that creates a global dijit.DialogUnderlay? We would then have to modify any widget that uses dijit.BackgroundIframe to pass a new flag to it and add that flag to the widget. Making it a global configuration option keeps the complexity down. Plus, if you have an applet in your application, you're going to want to make sure that everything that possibly could overlap it will overlap it without figuring out which widgets could possibly overlap it and possibly missing a few. Remember, this is for widgets that overlap applets, not widgets that will contain an applet.

comment:5 Changed 10 years ago by liucougar

sorry, I misunderstood. global option seems fine then

comment:6 Changed 10 years ago by bill

Owner: changed from bill to Bryan Forbes

Bryan - ok looks good to me, except that it isn't working on FF3.5/mac. The java app still interferes with the display. I guess it's better than nothing though, so go for it.

Good catch on the CSS expressions thing (a bit hard to believe that they reevaluate on mouse move, but I'll take the article's word for it).

I assume that width=height=100% doesn't work on IE6? Presumably that's the reason I did the fancy expression stuff originally.

I'm attaching an updated version of your test page w/a <select> node, for testing that <select> isn't hidden unnecessarily on IE.

Changed 10 years ago by bill

Attachment: test_bgIframe.html added

comment:7 Changed 10 years ago by Bryan Forbes

Resolution: fixed
Status: newclosed

(In [20187]) fixes #9805 !strict

  • Added flag to allow the BackgroundIframe? to be applied to all elements that may need it.
  • Removed CSS expressions for IE6 in favor of onresize event.
  • Added test with Bill's changes.

comment:8 Changed 10 years ago by bill

Resolution: fixed
Status: closedreopened

Unfortunately after this check dijit/tests/robot/Menu_mouse.html and dijit/tests/_base/robot/focus_mouse.html are failing on IE6. Not sure why. Can you fix?

comment:9 Changed 10 years ago by bill

Resolution: fixed
Status: reopenedclosed

Hmm, nevermind, now I'm seeing those failures even on [20186], I guess it's unrelated.

Changed 10 years ago by bill

Attachment: iframeSizing.png added

iframe too tall on IE6

comment:10 Changed 10 years ago by bill

Resolution: fixed
Status: closedreopened

Actually, turns out it is this checkin ([20187]) after all... the problem is that on IE6 the iframe is too tall:

iframe too tall on IE6

(see how it extends past the end of the edit menu). So in test_Menu.html if you click the Edit menubar button to open the Edit menu, and then click just below the bottom of the edit menu, the menu won't close because the iframe intercepts the mouse click.

comment:11 Changed 10 years ago by bill

Same problem on test_focus.html... intermittently (50% of the time), when the "push me" combobutton's menu is opened, none of the menu items are selected. It's caused because the iframe is again too tall, extending from the top of the menu past the bottom of the menu, covering up the top part of the combobutton. (Note that the menu is appearing above the button, not below it.)

Not sure why that obstructing iframe causes none of the menu items to be selected, but again there's a sizing issue w/the iframe.

comment:12 Changed 10 years ago by bill

Also apparently this is causing "error already called" errors in Menu_mouse.html on IE6.

comment:13 Changed 10 years ago by bill

Priority: normalhigh

comment:14 Changed 10 years ago by Douglas Hays

Type: enhancementdefect

comment:15 Changed 10 years ago by haysmark

Summary: No way to always apply a background iframe in dijit[patch] No way to always apply a background iframe in dijit

I attached a potential fix.

Changed 10 years ago by haysmark

Attachment: 9805.2.patch added

Fixes #9805. Added back an accidentally removed dojo.config parameter. Fixed copy-paste typo.

comment:16 Changed 10 years ago by bill

Resolution: fixed
Status: reopenedclosed

(In [20418]) Fix typo causing iframe to be sized incorrectly. Fixes #9805 !strict.

Also add back forceBgIframe dojo.config flag check mistakenly removed in [20190] (refs #4614).

Thanks to Mark for catching these problems.

comment:17 Changed 10 years ago by bill

Summary: [patch] No way to always apply a background iframe in dijitAdd flag to always apply a background iframe in dijit
Type: defectenhancement

Marking back as enhancement; although [20187] did cause a defect the actual point of this ticket is the new dojo.config.forceBgIframe flag support (allowing dialogs to work correctly when PDFs or java applets are embedded in dojo pages).

comment:18 Changed 10 years ago by bill

Summary: Add flag to always apply a background iframe in dijitDialog: hidden behind PDF or applet
Type: enhancementdefect

I guess I'll change this so it always does the background iframe on FF and IE, rather than having a flag Tt turns out we need it on IE8 anyway, see #10041.

comment:19 Changed 10 years ago by bill

(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:20 Changed 10 years ago by bill

(In [20589]) No longer need flag for background iframe, it's used all the time, refs #9805.

comment:21 Changed 9 years ago by bill

(In [23157]) Fix comment, refs #9805. Although, maybe there's some forgotten reason that the BackgroundIframe needs to be for the whole DialogUnderlay rather than just the dialog.

comment:22 in reply to:  21 Changed 9 years ago by ben hockey

Replying to bill:

...maybe there's some forgotten reason that the BackgroundIframe needs to be for the whole DialogUnderlay rather than just the dialog.

i'm just speculating, i don't know for sure, but could it be that you want the iframe to be for the whole underlay to ensure that the dialog is modal? that is, you don't just want the dialog to be over the content but you would want the underlay to sit over the content as well to prevent interaction with it. again, just speculating.

comment:23 Changed 9 years ago by bill

Maybe, although there's already a <div> for the (the DialogUnderlay? has a plain semi-transparent <div>).

It also might have been that Alex was complaining about bleed-through of selects (ie, selects not dimming like the rest of the page when the Dialog was shown) so I took the other of two evils by making them disappear completely.

Note: See TracTickets for help on using tickets.