You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@shindig.apache.org by "Matthew Reiter (JIRA)" <ji...@apache.org> on 2012/06/29 23:09:44 UTC

[jira] [Closed] (SHINDIG-1808) makeRequest fails on IE when ActiveX is disabled

     [ https://issues.apache.org/jira/browse/SHINDIG-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matthew Reiter closed SHINDIG-1808.
-----------------------------------


Verified that with the latest code makeRequest works on IE even when ActiveX is disabled.
                
> makeRequest fails on IE when ActiveX is disabled
> ------------------------------------------------
>
>                 Key: SHINDIG-1808
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-1808
>             Project: Shindig
>          Issue Type: Bug
>          Components: Javascript 
>    Affects Versions: 2.0.0
>         Environment: Internet Explorer 7+
>            Reporter: Matthew Reiter
>            Assignee: Stanton Sievers
>            Priority: Minor
>             Fix For: 2.5.0-beta3
>
>         Attachments: activex.patch, activex.patch
>
>
> When using Internet Explorer and ActiveX is disabled, makeRequest throws an exception creating the Msxml2.XMLHTTP ActiveXObject rather than falling back to XMLHttpRequest. This bug was introduced as part of the fix for the bug "IE7 XHR requests fail when gadgets contain a <base href="..."> tag" (https://issues.apache.org/jira/browse/SHINDIG-1194) because the order in which the two methods are attempted was reversed. The Wicket project encountered the same bug: "Problems concerning IE9 with "ActiveX Filtering" enabled" (https://issues.apache.org/jira/browse/WICKET-3887), but Shindig may not be able to make use of their fix due to the issues raised in the first bug. Thus my proposed solution is to wrap the ActiveXObject creation in a try-catch block and fall back to XMLHttpRequest if an error is encountered.
> Once that is out of the way, the same error will occur again later when attempting to parse the DOM (assuming that XML was returned) when creating Microsoft.XMLDOM because it doesn't fall back to DOMParser. For this, I propose reversing the order in which the two methods are attempted (try DOMParser first and then try Microsoft.XMLDOM if it fails) under the assumption that using DOMParser is the preferred method of parsing XML.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira