When I try to download or even browse from within the internal browser the following URL:
http://rutracker.org/forum/viewtopic.php?t=4675502
I get a message that the browser is old and the site may not be rendered correctly. Some of the div tags control the visibility of their nested contents. A grey line is shown instead.
I tried to change browser identification, also tried to use a custom string "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" as agent identification, but the result was just as the above.
http://rutracker.org/forum/viewtopic.php?t=4675502
I get a message that the browser is old and the site may not be rendered correctly. Some of the div tags control the visibility of their nested contents. A grey line is shown instead.
I tried to change browser identification, also tried to use a custom string "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" as agent identification, but the result was just as the above.
It is easy to overcome. Please use the Browse With AutoSave button to view this page correctly.
Best regards,
Oleg Chernavin
MP Staff
Best regards,
Oleg Chernavin
MP Staff
I downloaded the new 6.8 OE version and the downloaded page shows correctly within the internal browser, no matter whether the AutoSave button is on or off. However when I try to export the project as a CHM file the problem is reproduced exactly; if it is exported as a compressed exe viewer, it looks as the css is not working at all; when exported as a folder, the old browser message is gone, but the div layout problem persists.
I thought may be the IE compatibility mode in the embedded web browser was causing the problem, but adding
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
did not fix the problem.
I thought may be the IE compatibility mode in the embedded web browser was causing the problem, but adding
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
did not fix the problem.
Unfortunately, this is caused by IE (embedded web browser). For some reason it acts as an old version and the script on the page doesn't show the spoilers correctly because of that.
Offline Explorer uses Windows Registry to tell IE act as IE 11.0 inside Offline Explorer. It is because it writes a special Registry setting while installation in the administrative mode.
The exported EXE file runs in a usual mode and it cannot write that Registry value. So, IE inside the exported file acts as IE 8.0, as I understand.
I really don't know a good approach to overcome this export problem now.
Oleg.
Offline Explorer uses Windows Registry to tell IE act as IE 11.0 inside Offline Explorer. It is because it writes a special Registry setting while installation in the administrative mode.
The exported EXE file runs in a usual mode and it cannot write that Registry value. So, IE inside the exported file acts as IE 8.0, as I understand.
I really don't know a good approach to overcome this export problem now.
Oleg.
Yes, I agree, the old browser message is due to older IE modes implemented in the WebBrowser control. This can perhaps be overcome:
The X-UA-Compatible meta tag allows IE to be switched into different modes.
The Windows registry can also be modified for the CHM to display the WebBrowser in other than IE 7 mode (at least according to this article: http://weblog.west-wind.com/posts/2012/Feb/15/Make-your-CHM-Help-Files-show-HTML5-and-CSS3-content).
At least what happens when I export as a compressed exe viewer, is that the css link to the document is broken and no CSS rules are displayed.
However, according to me, the spoilers are not displayed for some JavaScript error - I open the "exported as a folder on a disk" html file in different document modes via the IE 11 emulation functionality - the spoilers are not displayed in any of the emulated IE versions; when I use the Firefox Web Developer tool, it looks as the JQuery $ variable is not recognized - here are the errors returned by Firefox (if I open the downloaded document in firefox through its local erver URL, no such errors are produced):
19:19:24.677 ReferenceError: $ is not defined main.js@v=50:226
19:19:24.680 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:261
19:19:24.680 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:274
19:19:24.681 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:323
19:19:24.685 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:433
19:19:24.686 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:580
19:19:24.697 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:751
19:19:24.697 TypeError: ajax is undefined viewtopic.php@t=4675502.htm:757
19:19:24.704 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:1116
19:19:24.705 TypeError: ajax is undefined viewtopic.php@t=4675502.htm:1230
19:19:24.721 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:1931
19:19:24.724 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:2052
19:19:24.729 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:2114
19:19:24.729 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:2162
The X-UA-Compatible meta tag allows IE to be switched into different modes.
The Windows registry can also be modified for the CHM to display the WebBrowser in other than IE 7 mode (at least according to this article: http://weblog.west-wind.com/posts/2012/Feb/15/Make-your-CHM-Help-Files-show-HTML5-and-CSS3-content).
At least what happens when I export as a compressed exe viewer, is that the css link to the document is broken and no CSS rules are displayed.
However, according to me, the spoilers are not displayed for some JavaScript error - I open the "exported as a folder on a disk" html file in different document modes via the IE 11 emulation functionality - the spoilers are not displayed in any of the emulated IE versions; when I use the Firefox Web Developer tool, it looks as the JQuery $ variable is not recognized - here are the errors returned by Firefox (if I open the downloaded document in firefox through its local erver URL, no such errors are produced):
19:19:24.677 ReferenceError: $ is not defined main.js@v=50:226
19:19:24.680 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:261
19:19:24.680 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:274
19:19:24.681 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:323
19:19:24.685 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:433
19:19:24.686 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:580
19:19:24.697 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:751
19:19:24.697 TypeError: ajax is undefined viewtopic.php@t=4675502.htm:757
19:19:24.704 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:1116
19:19:24.705 TypeError: ajax is undefined viewtopic.php@t=4675502.htm:1230
19:19:24.721 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:1931
19:19:24.724 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:2052
19:19:24.729 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:2114
19:19:24.729 ReferenceError: $ is not defined viewtopic.php@t=4675502.htm:2162
Browsing from the disk will not execute that javascript. JQuery is the AJAX technology and it requests data from a web server. If you are browsing from the disk, there is no web server and JQuery fails.
I can suggest you to write to the Registry:
32 bit only or 64 bit:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
DWORD Value: OEExport.exe
11000
32 bit on 64 bit machine:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
DWORD Value: OEExport.exe
11000
Export the Project to OEExport.exe file. Would this browse correctly?
Oleg.
I can suggest you to write to the Registry:
32 bit only or 64 bit:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
DWORD Value: OEExport.exe
11000
32 bit on 64 bit machine:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
DWORD Value: OEExport.exe
11000
Export the Project to OEExport.exe file. Would this browse correctly?
Oleg.
JQuery is quite a versatile JavaScript library and in this case besides subserving AJAX, it also adds clickable functionality to and reveals the spoilers. These two functions do not have to be interdependent. By trial and error, using the "Folder on a disk"export method, I managed to isolate and repair the spoiler problem. It seems that when exporting this project, the file jquery.pack.js is parsed and its contents are not the same as that of the original, which generates the JavaScript error. The contents of this file may be dynamic, but in my particular experiment I found out this difference in the jQuery library files:
original:
a.ActiveXObject&&o(a).on("unload",function(){for(var a in Dc)Dc[a]()}),l.cors=!!Fc&&"withCredentials"in Fc
parsed by OE:
a.ActiveXObject&&o(a).on("unload",function(){for(var a in Dc)Dc[a]()}),l.cors=!!Fc&&"withCredentials"in%20fc
Please look at the end of the string: %20 instead of space. There are also many subsequent instances of case differences, i.e. fc instead of Fc.
So can this parsing behavior be prevented when exporting?
Your registry editing suggestion did restore the CSS association when exporting to exe. Maybe it is a coincidence, but after that the spoilers vanished also in the internal browser. After that I deleted the registry entry and restarted the PC, the spoilers appeared in the OE just fine; I again added your registry value and they stayed. This erratic behavior is inexplicable to me.
original:
a.ActiveXObject&&o(a).on("unload",function(){for(var a in Dc)Dc[a]()}),l.cors=!!Fc&&"withCredentials"in Fc
parsed by OE:
a.ActiveXObject&&o(a).on("unload",function(){for(var a in Dc)Dc[a]()}),l.cors=!!Fc&&"withCredentials"in%20fc
Please look at the end of the string: %20 instead of space. There are also many subsequent instances of case differences, i.e. fc instead of Fc.
So can this parsing behavior be prevented when exporting?
Your registry editing suggestion did restore the CSS association when exporting to exe. Maybe it is a coincidence, but after that the spoilers vanished also in the internal browser. After that I deleted the registry entry and restarted the PC, the spoilers appeared in the OE just fine; I again added your registry value and they stayed. This erratic behavior is inexplicable to me.
Yes, thank you for finding this! I improved parsing code. Here is the updated OE.exe file version:
http://www.metaproducts.com/download/betas/OEE4075.zip
Regarding Registry entries - yes, it is MS IE which can read the Registry settings at different times, because it is almost always running on Windows and it is hard to understand its logic!
Oleg.
http://www.metaproducts.com/download/betas/OEE4075.zip
Regarding Registry entries - yes, it is MS IE which can read the Registry settings at different times, because it is almost always running on Windows and it is hard to understand its logic!
Oleg.
Thank you, Oleg! I tried your beta version. It works fine when I export in a folder on a disk and I had to change Windows Registry similarly to your suggestion for OEExport.exe for compiled CHM files also to render their contents in IE 11 mode:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION]
"hh.exe"=dword:00002af8
When I try to export as exe however, I get a "Document not found" error page.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION]
"hh.exe"=dword:00002af8
When I try to export as exe however, I get a "Document not found" error page.
Can you try to install this update:
http://www.metaproducts.com/download/betas/eesetup.exe
Would it work after exporting?
Oleg.
http://www.metaproducts.com/download/betas/eesetup.exe
Would it work after exporting?
Oleg.
Thank you very much, Oleg! Now export to exe works also, and there is no need to add a registry value for the browser emulation as you have suggested. The WebBrowser control is in IE 7 mode, which causes the above layout problems, but these can be overcome easily by adding the following meta tag in the head of the HTML document:
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
OK. Good. I added this line to HTML files exported to folder and MHT/CHM formats.
Oleg.
Oleg.
At least according to my experience, CHM ignores that meta tag and needs registry value to be added and there is no need of that line when exporting to folder.
I see. However I am not sure about adding this Registry value for another application. Moreover, CHM files most probably are browsed on other computers with no OE installed.
Oleg.
Oleg.
Yes, this is not an OE related issue. I mentioned it in case anyone has similar problems with CHM files, because they can be solved easily. This is once again the link I used for CHM registry modification:
http://weblog.west-wind.com/posts/2012/Feb/15/Make-your-CHM-Help-Files-show-HTML5-and-CSS3-content
I only used IE 11, not IE 9 values as shown there in the example. As this registry value has nothing to do with OE, the CHM files can be viewed correctly with registry modified and no need for OE to be installed.
http://weblog.west-wind.com/posts/2012/Feb/15/Make-your-CHM-Help-Files-show-HTML5-and-CSS3-content
I only used IE 11, not IE 9 values as shown there in the example. As this registry value has nothing to do with OE, the CHM files can be viewed correctly with registry modified and no need for OE to be installed.
I am really wondering, why Microsoft decided to make this kind of compatibility issues. They look really outdated now.
Oleg.
Oleg.
I myself was looking in vain for a way to use a particular version of IE Trident engine independently of the host operating system to display HTML contents but it is not an easy task. Or OE for Linux. for example... :)
I am not sure this is possible at all.
Oleg.
Oleg.