On May 25, 6:06 pm, Bob Kerns <r...@acm.org> wrote:
> This happens frequently -- in some circumstances most of the time, in
> others, occasionally. I don't understand exactly why.
>
> I'm using multiple iframes, and AJax (not the stuff in prototype, at
> least not at the moment). I frequently get an error dialog, which
> through painful tracing appears to happen somewhere either in or
> shortly prior to delivery of the readystatechange event:
>
> --- begin dialog
> One or more ActiveX controls could not be displayed because either:
> 1) Your current security settings prohibit running ActiveX controls on
> this page, or
> 2) You have blocked a publisher of one of the controls
>
> As a result, the page might not display correctly.
> --- end dialog
>
> I have no ActiveX controls, other than the native Ajax XMLHttpRequest
> object (I removed the legacy ActiveXObject versions in the process of
> narrowing this down).
>
> After a long session of divide-and-conquer elimination, I've traced
> this down to the function checkDeficiency(tagName), apparently applied
> to 'object'. (I didn't circle back and verify whether it also happens
> with 'applet').
>
> A quick workaround, probably not ideal, is to add this line to the
> Prototype.Browser object:
>
> IE8: !!(navigator.userAgent.indexOf('Trident/' > -1)),
>
> and this line as the first line of checkDeficiency():
>
> // Makes you get an ActiveX warning, on page unload?
> if (Prototype.Browser.IE8) return false;
>
> I don't understand exactly what deficiency is being worked around
> here, so I don't know if there are any consequences in short-
> circuiting this test.
>
> I'm also not completely sure of my characterization of when and where
> this dialog is triggered. However, it really does not seem to happen
> on initial page load?
>
> However, this patch does seem to reliably eliminate the error dialog.
It would definitely help to know what exactly causes a dialog (i.e. a
minimal test case reproducing this bug). We are aware of a similar
issue when IE pops up a dialog as soon as APPLET element is created in
IE8 which has no Java installed. The reason for `checkDeficiency` is
somewhat explained in this comment <http://github.com/kangax/prototype/
blob/9020365266347c5fb1e7cd17ac118fce104fd565/src/dom/dom.js#L1630>
Unfortunately, the "patch" you mention is based on `userAgent`-based
sniffing and `userAgent`-based sniffing is known to be very brittle
and inefficient when it comes to taking care of browser
inconsistencies.
There's a patch in the works which takes care of the APPLET issue, if
you're interested <http://github.com/kangax/prototype/commit/
9020365266347c5fb1e7cd17ac118fce104fd565>
--
kangax
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---
