TADS Bug Database

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000194TADS 3Interpreterpublic2013-05-03 14:072013-05-09 18:22
Assigned ToMichael Roberts 
PlatformFrobTADSOSLinuxOS Version
Summary0000194: No popup dialogs in webplay on IE9
DescriptionWhen web game is played on Internet Explorer 9, no popup windows are shown, only the background is darkened. No save restore dialogs, no hints, no instructions etc. When IE9 is switched (through built-in developer tools) into IE8 mode, everything is fine.
TagsNo tags attached.
Fixed In Version3.1.3
Attached Files

- Relationships

-  Notes
Michael Roberts (administrator)
2013-05-03 14:10

I don't have an IE9 installation at the moment to test with. Any chance you could fire up the developer tools (press F12) and track down what's going wrong with the javascript? Hopefully it's some simple script error that will show up as a javascript error on the console. I'll be happy to incorporate any changes you figure out.
tomasb (reporter)
2013-05-03 14:29

Ok, I will try to look into it more deeply, it just will take some time. I've just noticed that for example font configuration dialog is hidden under game and instead of HTML elements it has some prototypes which are probably meant to be replaced by actual elements. So something in the javascipt is not firing or so. But no, no simple js error on console is shown. I need to read more of the code to know better how it should work.
Michael Roberts (administrator)
2013-05-03 15:42

Great - thanks for looking into it. Let me know what you find, or if you need an explanation for any of the js code.
Michael Roberts (administrator)
2013-05-07 02:33

Good news - I think I have a solution. I was able to look at this after all by setting up a VM environment for IE9 (Microsoft makes VM images for IE 7-10 available for just this kind of version-specific testing and debugging - it's painfully slow, but it does the job). At any rate, it looks like the problem is pretty simple: there's some code that adjusts the dialog opacity that's specifically disabled for IE, because IE versions <= 8 didn't support it, but IE 9 finally caught up with the 90s and implemented CSS standard opacity. I'd appreciate it if you could test it out in your version, since you're presumably running a real IE 9 rather than a VM emulation like I am - just want to make sure that it fixes it on the actual IE 9 before I declare the bug fixed. Here's the fix: in lib/webuires/main.js, at line 1019, you should see this:

        // set it opaque
        if (!BrowserInfo.ie)
            canvas.style.opacity = "1";

The fix is just to take out the whole "if" line, leaving the next line intact with no condition.

If you have a chance, make the change to your copy of main.js, and build a default Adv3 Web UI sample game with Workbench, and run it with IE 9. If all goes well you should see the prefs dialog now.

(I'm going to have to double-check that removing the 'if' test won't cause problems on older IE versions. I might have to leave the test in and add a version-specific check instead. This kind of code normally doesn't need a test at all, since browsers that don't support the feature usually just ignore style settings like this, but the fact that I had the test in there makes me think it was needed to avoid a javascript error in old IE versions. At any rate, for testing purposes to make sure it fixes the problem with IE 9, you can just remove the 'if' test for now.)
Michael Roberts (administrator)
2013-05-07 02:52

Actually, try this instead: replace the pair of lines

        if (!BrowserInfo.ie)
            canvas.style.opacity = "1";


        setAlpha(canvas, 100);

I forgot that there's already a routine to cover browser differences for opacity settings - that should take care of my concerns about older IE versions. Let me know if that works for you.
tomasb (reporter)
2013-05-07 07:20

Well, I have a real IE9 on virtualized Windows 7 at hand, that's the closest to the real thing I can get. Apart from that I also run IE tester which allows me to see webpages under different versions of IE, but it is a really unstable piece of software and not 100% close to the real thing.

I've tested your suggestions and actually the first one with removing condition worked for me (afaik flawlessly), nonetheless the setAlpha did not. Although setAlpha managed to display dialog window (ie. hints), dialog was lost again in reaction to click any link in the dialog, so I was unable to navigate into a submenu.

In font preferences dialog with setAlpha, I was able to click on rename profile on top of the dialog, but when I subsequently closed rename dialog by top right cross icon, not only rename, but again whole preferences dialog was lost, only dark background remained. And again, with the first suggestion, it appeared to work flawlessly.

I've also tried the first suggestion in IE 7 and 8 (in IE tester), Firefox 12 and Chrome 26 and it appeared ok, but cannot guarantee that.

I don't have IE 10 at hand, but since I have Windows 7 virtualized, I can give it a try if you wish (and then revert to the previous snapshot with IE 9 easily), but I would prefer to do it as a last step when we are quite confident, that the bug is fixed.
Michael Roberts (administrator)
2013-05-07 13:39

Thanks for all the testing - really surprising results, which is exactly why it's good to test. :) I would have thought my virtualized Win7/IE9 would be identical to yours - your setup sounds like exactly what I'm running, although the VM images undoubtedly have separate provenances, so we might have slightly different Win7 or IE build configurations. Maybe there are subtle differences in quirks between builds of IE9 - there are certainly enough different quirks between major versions - or maybe it has something to do with the virtualized graphics hardware in our respective environments. In any case, my guess is that your version of IE9 must include support for both <element>.style.alpha and <element>.filters, whereas mine *only* supports CSS alpha styling, and doesn't report the presence of <element>.filters.

So here's my next attempt. Put the setAlpha() call back in place (with no 'if', of course) in main.js, and replace function setAlpha() in util.js with this code:

function setAlpha(ele, pct)
    ele = $(ele);
    if (ele.filters)
        // IE's typically overwrought approach
        pct = Math.floor(pct);
        if (ele.filters.alpha)
            // already have an alpha filter - set it directly
            ele.filters.alpha.opacity = pct;
            // No alpha yet - add it via the style. In IE8+, the filter
            // name requires the full "progid:DXImageTransform..." notation;
            // otherwise that notation isn't allowed, and we have to use
            // the simple "alpha" name.
            var fn = (BrowserInfo.ie && BrowserInfo.ie >= 8
                      ? "progid:DXImageTransform.Microsoft.Alpha" : "alpha");
            var f = fn + "(opacity=" + pct + ")";

            // if we have any filters, append this to the existing filter
            // style string, otherwise just set the initial filter style
            if (ele.filters.length > 0)
                ele.style.filter += " " + f;
                ele.style.filter = f;

    // everyone else just uses the 'opacity' style
    try { ele.style.opacity = "" + pct/100; } catch (e) { }

That *should* cover all the bases for any version of IE without testing for version numbers, which I hate doing because it's brittle against future versions. I'd also much rather get this working with setAlpha(), because that's used elsewhere in the code - if setAlpha() isn't working in this case, other things will probably break as well, so it'd be good to get the common code path working.
tomasb (reporter)
2013-05-09 09:56

Thank you Mike, that worked. I was curious, so I've tried evaluate (for
example) document.getElementById('prefsDialog').filters and developer
tools shows the following:

[object] {
        length : 0

So it seems to me, that filters property is set in my environment,
although empty, so the property definitelly exists here.

There seems to be signs indicating it may be differece between standards
mode and quirks mode (https://github.com/remy/jsbin/issues/119 [^]) but on
http://stackoverflow.com/questions/6987625/filters-collection-unavailable-on-some-versions-of-ie9 [^]
and suggestion to prefer opacity
(http://blogs.msdn.com/b/ie/archive/2010/08/17/ie9-opacity-and-alpha.aspx [^])
but nothing really concrete. Still I'm not sure, what the difference
between our environments is.

I should say I have slightly modified main.js file (translated and few
additional commands in menu), but none should interact in this case.
Michael Roberts (administrator)
2013-05-09 18:22

Great! Thanks for all the testing. Looks like we have a solution - I've applied the last version to my sources for the next update. Hopefully there's not yet another set of quirks in another IE version/configuration that breaks this code, but for now it looks like we have all of the variations covered.

- Issue History
Date Modified Username Field Change
2013-05-03 14:07 tomasb New Issue
2013-05-03 14:10 Michael Roberts Note Added: 0000341
2013-05-03 14:10 Michael Roberts Assigned To => Michael Roberts
2013-05-03 14:10 Michael Roberts Status new => feedback
2013-05-03 14:29 tomasb Note Added: 0000342
2013-05-03 14:29 tomasb Status feedback => assigned
2013-05-03 15:42 Michael Roberts Note Added: 0000344
2013-05-03 15:42 Michael Roberts Status assigned => feedback
2013-05-07 02:33 Michael Roberts Note Added: 0000351
2013-05-07 02:52 Michael Roberts Note Added: 0000352
2013-05-07 07:20 tomasb Note Added: 0000353
2013-05-07 07:20 tomasb Status feedback => assigned
2013-05-07 13:39 Michael Roberts Note Added: 0000354
2013-05-07 13:39 Michael Roberts Status assigned => feedback
2013-05-09 09:56 tomasb Note Added: 0000355
2013-05-09 09:56 tomasb Status feedback => assigned
2013-05-09 18:22 Michael Roberts Fixed In Version => 3.1.3
2013-05-09 18:22 Michael Roberts Note Added: 0000356
2013-05-09 18:22 Michael Roberts Status assigned => resolved
2013-05-09 18:22 Michael Roberts Resolution open => fixed

Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker