In OEP`s browser pane, In address bar, type:
http://www.hemera.com/
Notice the large blank area in upper left.
Now do the same thing in Internet Explorer, or in Mozilla Firefox.
That area now contains a large image (currently, christmas-colored candies).
Here is the HTML code:
<img src="images/trans.gif" alt="" width="564" height="278" name="rotation"><br>
<script tyupe="text/javascript">
<!--
show_banner();
//-->
</script>
Perhaps what confused OE is the TYPO <script tyupe...>
because site author misspelled "tyupe", the script doesn`t declare itself to be javascript.
In this case, the browser should DEFAULT to javascript anyway...
http://www.hemera.com/
Notice the large blank area in upper left.
Now do the same thing in Internet Explorer, or in Mozilla Firefox.
That area now contains a large image (currently, christmas-colored candies).
Here is the HTML code:
<img src="images/trans.gif" alt="" width="564" height="278" name="rotation"><br>
<script tyupe="text/javascript">
<!--
show_banner();
//-->
</script>
Perhaps what confused OE is the TYPO <script tyupe...>
because site author misspelled "tyupe", the script doesn`t declare itself to be javascript.
In this case, the browser should DEFAULT to javascript anyway...
No, it works perfectly in Offline Explorer. I saw candies, church and a window pictures there. It doesn`t matter if there is a typo or not - Offline Explorer uses embedded MS IE window as its Internal Browser.
Best regards,
Oleg Chernavin
MP Staff
Best regards,
Oleg Chernavin
MP Staff
Well, perhaps I should not bother reporting bugs to you, if you dismiss my report, just because it works on your computer.
There must be something about the computer which I encountered this problem on, that caused OE to behave differently.
And note the very important fact that on that computer, when I entered the address directly in an IE browser, the problem did not occur. This proves that there is something different about how the IE browser is working inside OE`s browser (at least on that computer), than when IE is on its own.
However, if no one else encounters this problem, then by all means chalk it up to the complexities of different configurations of browsers, brower settings, add-ons, and versions of windows OS patches.
There must be something about the computer which I encountered this problem on, that caused OE to behave differently.
And note the very important fact that on that computer, when I entered the address directly in an IE browser, the problem did not occur. This proves that there is something different about how the IE browser is working inside OE`s browser (at least on that computer), than when IE is on its own.
However, if no one else encounters this problem, then by all means chalk it up to the complexities of different configurations of browsers, brower settings, add-ons, and versions of windows OS patches.
Interesting. I just went back and tried it again on the offending computer. Now everything works okay. What`s different about now and then is that I had to restore that computer to a Restore Point just before Christmas, due to other symptoms. So something was messed up on that computer.
Yes, it is interesting what could be wrong. One possible reason is a firewall application that doesn`t allow OE to do certain actions, but allows everything to MS IE.
In fact, I am glad if users provide me with bug reports that can be or cannot be reproduced on my computer. This helps me to see the real picture and to find ways to workaround issues that many other users may face.
Oleg.
In fact, I am glad if users provide me with bug reports that can be or cannot be reproduced on my computer. This helps me to see the real picture and to find ways to workaround issues that many other users may face.
Oleg.
My point was that rather than saying:
"No, it works perfectly in Offline Explorer."
it would have been more appropriate to say:
"When I try this, it works perfectly in Offline Explorer."
That is to say, after my report and your report, all we know is that it worked on one computer, and not on another. To say "No", just because it worked for you, was incorrect and somewhat rude.
Unless we were to ask a hundred different users to try it, we don`t know yet whether it is something peculiar about the computer I was running on, or would happen on other people`s computers, if they went to this website.
Tell me more about how the browser pane works, and maybe I can figure out what was going on.
Specifically, what might be different between:
1. typing "http://www.whatever.com/" into the address bar, and
2. AutoSave browsing, which shows "http://127.0.0.1:800/Default/www.whatever.com/" in the address bar?
That is, as the page asked for the URLs it needed, to load IMGs on the page, is there any difference in the request sent to the server, in these two cases?
Ideally, all fields of the request would look identical in the two cases.
- - - - -
Another possibility: I had to roll back this computer to a previous restore point because DCOM communication that MSIE uses to open new windows was failing to open the new windows, suggesting some DCOM Interface or some Access Permissions had been corrupted - in searching Microsoft`s knowledge base, I see that this is a problem that has surfaced several times over the years in different versions of MSIE, requiring MS to release patches - XP Service Pack 2 must be somehow involved, though I use that fine on other systems.
I guess Autosave browsing mode was being affected by whatever was messed up on this system.
"No, it works perfectly in Offline Explorer."
it would have been more appropriate to say:
"When I try this, it works perfectly in Offline Explorer."
That is to say, after my report and your report, all we know is that it worked on one computer, and not on another. To say "No", just because it worked for you, was incorrect and somewhat rude.
Unless we were to ask a hundred different users to try it, we don`t know yet whether it is something peculiar about the computer I was running on, or would happen on other people`s computers, if they went to this website.
Tell me more about how the browser pane works, and maybe I can figure out what was going on.
Specifically, what might be different between:
1. typing "http://www.whatever.com/" into the address bar, and
2. AutoSave browsing, which shows "http://127.0.0.1:800/Default/www.whatever.com/" in the address bar?
That is, as the page asked for the URLs it needed, to load IMGs on the page, is there any difference in the request sent to the server, in these two cases?
Ideally, all fields of the request would look identical in the two cases.
- - - - -
Another possibility: I had to roll back this computer to a previous restore point because DCOM communication that MSIE uses to open new windows was failing to open the new windows, suggesting some DCOM Interface or some Access Permissions had been corrupted - in searching Microsoft`s knowledge base, I see that this is a problem that has surfaced several times over the years in different versions of MSIE, requiring MS to release patches - XP Service Pack 2 must be somehow involved, though I use that fine on other systems.
I guess Autosave browsing mode was being affected by whatever was messed up on this system.
The difference between these modes is the following - the first URL is being processed by MS IE with no OE intervention. The second goes to the Offline Explorer`s internal server. The server sends a message to OE that a URL is missing and it should be probably added to the Project. OE adds the URL and starts loading it using its own downloading code. The request will be different a bit from what uses MS IE, but not significantly. At least all cookies should be kept. The only missing thing is Referer. Maybe it is the problem?
Oleg.
Oleg.
Yes, if Referer is missing, then that is the problem.
(To help protect their copyrighted material, these sites treat requests coming from external URLs differently than requests coming from their own pages.)
I may be mistaken about Referrer being the cause.
I just did "Save As" on www.hemera.com in MSIE. Then loaded the saved result back into MSIE. There is the blank image!
Upon further investigation, the URL for that image is now "file:///D:/images/home/rotation1.jpg".
=> Ah-ha! That looks suspiciously like the "URLs starting with a slash" bug I mentioned in another thread. But I`ve done all this in MSIE, so OE isn`t involved.
Searching the source HTML using FrontPage, the only mention of "rotation" is:
<TD colSpan=7><IMG height=278 alt=""
src="HEMERA_files/trans.gif"
width=564 name=rotation><BR>
<SCRIPT tyupe="text/javascript">
<!--
show_banner();
//-->
</SCRIPT>
</TD>
- - - - - - - - - -
And going back to MSIE, I then realize status says [yellow warning triangle]"Done, but with errors on page".
Double-click on yellow triange, error is Line: 25, object expected.
Looking at HTML, line 25 is script reference to "sitescripts.js".
Looking at MSIE`s saved "sitescripts.js", I see several functions. Haven`t yet figured out exactly what`s going on, but it has to be something like this:
somewhere in some javascript, there is a URL starting with "/". For reasons I don`t yet understand, MSIE is now interpreting this relative to the file system [here, drive D:], instead of relative to the current URL path [what was "http://www.hemera.com/" and is now "file://D:/Temp/HEMERA.htm"].
This appears to be either a bug in javascript or in MSIE.
I ought to report this to Microsoft, but I hate to do so without spending more time exploring it, to make a simpler example, and to make sure I`m not wrong.
What`s needed is to make a simpler web page that MSIE downloads, showing the same bug.
Since I`m currently re-training myself on website programming, I might be able to justify the time to explore this. I`ll keep you posted.
I just did "Save As" on www.hemera.com in MSIE. Then loaded the saved result back into MSIE. There is the blank image!
Upon further investigation, the URL for that image is now "file:///D:/images/home/rotation1.jpg".
=> Ah-ha! That looks suspiciously like the "URLs starting with a slash" bug I mentioned in another thread. But I`ve done all this in MSIE, so OE isn`t involved.
Searching the source HTML using FrontPage, the only mention of "rotation" is:
<TD colSpan=7><IMG height=278 alt=""
src="HEMERA_files/trans.gif"
width=564 name=rotation><BR>
<SCRIPT tyupe="text/javascript">
<!--
show_banner();
//-->
</SCRIPT>
</TD>
- - - - - - - - - -
And going back to MSIE, I then realize status says [yellow warning triangle]"Done, but with errors on page".
Double-click on yellow triange, error is Line: 25, object expected.
Looking at HTML, line 25 is script reference to "sitescripts.js".
Looking at MSIE`s saved "sitescripts.js", I see several functions. Haven`t yet figured out exactly what`s going on, but it has to be something like this:
somewhere in some javascript, there is a URL starting with "/". For reasons I don`t yet understand, MSIE is now interpreting this relative to the file system [here, drive D:], instead of relative to the current URL path [what was "http://www.hemera.com/" and is now "file://D:/Temp/HEMERA.htm"].
This appears to be either a bug in javascript or in MSIE.
I ought to report this to Microsoft, but I hate to do so without spending more time exploring it, to make a simpler example, and to make sure I`m not wrong.
What`s needed is to make a simpler web page that MSIE downloads, showing the same bug.
Since I`m currently re-training myself on website programming, I might be able to justify the time to explore this. I`ll keep you posted.
In fact, it shows a problem with MS IE - it doesn`t change script links. OE changes such links, but sometimes it also fails (very very rarely).
Oleg.
Oleg.