Curious IE 6 SP2 error.

[Duncan]

I'm getting a pretty weird scenario unfolding in a web application
where I work. I wonder if anyone can help me out?

Theres a portal application with multiple "child" applications, with
the child application served from several different web servers.

The portal works using frames, with one frame remaining on the portal
domain and another frame going over to the child application.

In one of these applications there is a data entry form which. On this
form there are several links. These links refer to empty bookmarks,
and, via the capture of the onclick event, go to a second server side
page. The server side page does some processing (in this case adds
another element to the forms definition). Then redirects to the
original page.

With me so far?

Right, here is where it gets a little odd. On the form submit/cancel
buttons there are typical mouseover events to change the images. These
fail with a "permission denied" error. The javascript is all dead.
Yes, there are some cross frame calls going on, but not in this section
of code. What's more if you refresh the page everything works fine.
Naturally the same page works correctly in IE 6 SP1, Firefox, mozilla,
etc etc.

The very weirdest part is that internet explorer seems to have
'forgotten' where the page is. Looking at the properties for the frame
everything is unavailable, from protocol all the way down (well ok, it
figures out the page isn't encrypted).

With the page refreshed all the properties information is correctly
populated and the javascript works...

To cut to the chase it looks as if the page is somehow missing the
basic information about where it is from, and can't be placed in the
correct security context, and then can't access any javascript...
or...? Hell I don't know, I'm just about done with it all

Odd that the refresh just makes it work, but I can hardly recommend
that as the chosen technical solution, especially when one half of the
customers know that the other half are having no problems at all with
older/other browsers...

Anyway, any help appreciated, (even if it's just pointing to a more
suitable forum)

Many thanks,

Duncan.

 

[s_m_b]

What we really need is some examples of the javascript, since that
appears to be the culprit.
Might be able to more clearly redirect the problem then.

 

[Duncan]

Heh, no mind-reading eh?

I shan't post any of the script as I don't think it would do anything
other than take up some of your time without reason. The javascript is
typical rollover code and vanilla form.submit() stuff that does not
contain any errors. Honestly, no errors are present. The only thing
it does a little badly is refer to the deprecated "arguments" property
of a function, but that isn't sooo bad.

The opinion here is now that the page "loses" itself. If you get a
similar "Permission Denied" error on a page where the Javascript isn't
doing something obviously insecure, such as cross frame scripting, then
take a look at the properties for the frame. If you get back a
dialogue with all the values set to "Not Available" (except for
encryption, where the value is "Not encrypted", then you've likely hit
this peculiar bug. The upshot is that scripts that refer to the DOM
stop working. No document.images, no document.parent, etc etc.
Curiously if the page can be refreshed, then the new version of the
page will work happily.

Looking at the page received in the refresh it is identical to the
original broken page, and thats based on intercepting the
request/response messages with a proxy tool. Of course, looking at
properties for the refreshed, working page, show the expected set of
values, rather than "Not available".

The final solution we implemented here, pending word from MS, is to
have the server detect if a browser is IE 6 SP2, and if it is the first
request for a particular instance of the page, then to send a very
short page telling the browser client to refresh the page straight away
(using META tag).

Very ugly, but it's a shorter less expensive option than trying to get
to the bottom of this one.

I do not tend to immediately jump on the "blame MS" band-wagon, but
this time, I'm 90% confident that this is a real bug in IE 6 with XP
SP2 installed. Most likely related to a security context check for
javascript falling through with an unhandled situation.

I'm very happy to be wrong by the way, so if you know better, please
let me know.

 

[kdarling]

The opinion here is now that the page "loses" itself. If

I'm curious: are all of you using gzip compression in your replies to
the client? We'd had to work around so many compression reply bugs
it's not even funny. Page reloads will make .css files disappear.
Second POST replies will similar urls are reused by the browser. Some
of these are known (search msdn.microsoft.com for "internet explorer
gzip" or "internet explorer compression"), some aren't.

Luck!
Kev

 

[Duncan]

Sorry for not replying sooner, time is short and all that jazz.

The page did reference external scripts, and also had in-page script as
well. With regard to the anchors - our links did include anchors on
the link that broke the page. I can't recall at the moment if the
refresh included the anchor details when resubmitting...

I would be interested to find someone who had managed to recreate this
consistently. All of our attempts to create a small test wherein this
problem could be recreated failed (albeit in our defense I would add we
didn't spend *that* long looking at it!).

I hope you get around the problem, I also hope this problem gets
recorded/explained somewhere in the MS knowledge base. Getting it
inadvertantly fixed in some subsequent security patch would be a bit
annoying for some of our service desk people. Several of our customers
seem to take forever to approve and roll out the patches and asking a
normal user what build/patch number they have on their machine gets
annoying very quickly!

Best regards,

Duncan

 

[Robert Aldwinckle]

Sorry for not replying sooner, time is short and all that jazz.

The page did reference external scripts, and also had in-page script as
well. With regard to the anchors - our links did include anchors on
the link that broke the page. I can't recall at the moment if the
refresh included the anchor details when resubmitting...

I would be interested to find someone who had managed to recreate this
consistently. All of our attempts to create a small test wherein this
problem could be recreated failed (albeit in our defense I would add we
didn't spend *that* long looking at it!).

Did you compare the headers of your simulation
with the headers of the problem case?
Were the same servers used in each case?

My guess is that your symptom will be explained by caching.
FYI there are some headers which some servers send
(e.g. vary: which Apache sends) which have evidently
affected the cacheability of a file unexpectedly.


HTH

Robert Aldwinckle
---

 

[Guest]

Hi, I'm on here reading thru the threads searching for answers and I came
across this very problem that I was dealing with. Scenario is logging on to
a secured site. Logged in attempting to access a left menu bar with various
options to click on to direct me to diffrent pages: ex. reporting, I click on
it and immediatly blocks access to every button on the menu bar. message at
bottom on the main secured webpage is: page error, clicking on the icon
displaying page error reveals line# char: errorermission denied
code: 0 then the, url https:site
I attempted the refresh trick after I got the page error and I now could
access any of the buttons on the left Menu bar giving me access to the pages.
Wierd thing is that I have IE 6 and Win XP Home SP2 on my other computer
also and no problem. I seemed to have found the work around thru these
threads
Thank You

 

[Guest]

I have a similar problem. Code that used to work before I applied some MS IE
security patches no longer works now.

The code is this:

<FRAMESET ...>
<FRAME NAME=comdFrame SRC="/sd/empty.html">
....
</FRAMESET>

and the error occurs on the following javascript line:

var cmdFrame = top.comdFrame.window.document;

or more precisely when accessing the "window" property of the comdFrame
object.

What I ultimately want to accomplish is cmdFrame.location = "some new URL";

Can I get around this problem in any way? Do you need more info?

Thanks,
Vladimir

 

[Guest]

Robert
Thanks for the info.
It was a consistant page error. Irronicaly, I was doing some webpage stuff
and needed to change the the java script program that was on the computer
that was giving me the recurring error as explained in the prior thread. So
on installing the replacement javascript progaming Sun Java the problem
vanished. I'm not recieving the page error when accessing the website and
clicking on a page link.
No need to hit refresh to access the page link as before which was the work
around that I had come across on the prior threads. Maybe this was of some
help, for me it inadvertantly stumbled on after the Sun Java install.
ztim