>From all the help sites which have had to deal with this issue that I have
seen, it needs to be in place before everything else, including javascript,
right after the <html><head> tags on HTML. This all depends on how IE
behaves thou. I'm stuck with requiring compatibility view enabled for all
intranet sites because noone is going to update the older hardwired for
IE5.5 pages. I suggest you turn on that compatibilty view settings as well
while testing. If I knew how to handle tomcat's coyote better, I could try
setting configuration in coyote instead of using urlrewritefilter for
sending the x-ua-compability info in the response header.


On Tue, Sep 16, 2014 at 10:18 AM, Maxim Solodovnik <solomax...@gmail.com>
wrote:

> so I should add
>
> <meta http-equiv="X-UA-Compatible" content="IE=Edge" />
>
> to all OM pages
> correct?
>
> On 16 September 2014 21:08, William Overstreet <
> william.ab.overstr...@gmail.com> wrote:
>
>> http://msdn.microsoft.com/en-us/library/ff955275%28v=vs.85%29.aspx
>>
>> On Mon, Sep 15, 2014 at 9:53 AM, William <william.ab.overstr...@gmail.com
>> > wrote:
>>
>>> You did supply the correct meta tags. The problem is that those tags
>>> have to be first, or ie will start processing with the older engine and
>>> ignore them. Throwing them in the http response header guarantees the page
>>> to be handled by the non-ie7 rendering engine. It is somewhere in the IE
>>> support spec that this is actually a proper way to do this. I'll have to
>>> dig up the document.
>>>
>>> On Sep 13, 2014, at 2:40, Maxim Solodovnik <solomax...@gmail.com> wrote:
>>>
>>> Maybe we can set some IE specific META? I can add it to the page if you
>>> can tell me with META should be added
>>>
>>> On 13 September 2014 01:39, William Overstreet <
>>> william.ab.overstr...@gmail.com> wrote:
>>>
>>>> Well, turns out that if compatibility view is enabled, and the first
>>>> thing through isn't the webs server telling the browser to use the latest
>>>> and greatest, the browser falls back to IE7 compatibility, which does not
>>>> work. I'm using urlrewritefilter-4.0.3.jar to make the internal tomcat web
>>>> server send the headers to force IE to use the latest.
>>>>
>>>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/lib/urlrewritefilter-4.0.3.jar
>>>>
>>>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/web.xml
>>>> ${RED5_HOME}/webapps/openmeetings/WEB-INF/urlrewrite.xml
>>>>
>>>> # diff web.xml web-old.xml
>>>> 37,48d36
>>>> <     <filter>
>>>> <         <filter-name>UrlRewriteFilter</filter-name>
>>>> <
>>>> <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
>>>> <     </filter>
>>>> <
>>>> <     <filter-mapping>
>>>> <         <filter-name>UrlRewriteFilter</filter-name>
>>>> <         <url-pattern>/*</url-pattern>
>>>> <         <dispatcher>REQUEST</dispatcher>
>>>> <         <dispatcher>FORWARD</dispatcher>
>>>> <     </filter-mapping>
>>>> <
>>>>
>>>> # cat urlrewrite.xml
>>>> <?xml version="1.0" encoding="utf-8"?>
>>>> <!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 4.0//EN" "
>>>> http://www.tuckey.org/res/dtds/urlrewrite4.0.dtd";>
>>>>
>>>> <urlrewrite>
>>>>
>>>>         <rule>
>>>>                 <condition
>>>> type="request-uri">^(/openmeetings/wicket.*)$</condition>
>>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>>                 <set type="response-header"
>>>> name="X-UA-Compatible">IE=Edge</set>
>>>>         </rule>
>>>>         <rule>
>>>>                 <condition
>>>> type="request-uri">^(/openmeetings/swf.*)$</condition>
>>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>>                 <set type="response-header"
>>>> name="X-UA-Compatible">IE=Edge</set>
>>>>         </rule>
>>>>         <rule>
>>>>                 <condition
>>>> type="request-uri">^(/openmeetings/)$</condition>
>>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>>                 <set type="response-header"
>>>> name="X-UA-Compatible">IE=Edge</set>
>>>>         </rule>
>>>>         <rule>
>>>>                 <condition
>>>> type="request-uri">^(/openmeetings/screen.upload.*)$</condition>
>>>>                 <condition name="user-agent">.*MSIE.*</condition>
>>>>                 <set type="response-header"
>>>> name="Cache-Control">max-age=5</set>
>>>>         </rule>
>>>> </urlrewrite>
>>>>
>>>>
>>>>
>>>> On Thu, Sep 11, 2014 at 11:17 AM, William Overstreet <
>>>> william.ab.overstr...@gmail.com> wrote:
>>>>
>>>>> Thanks for that, was getting nailed with the Compatibility view. For
>>>>> some reason corp says we need it turned on reasons. I guess I can edit the
>>>>> pages to present the correct html to force non-compatibility view.
>>>>>
>>>>>
>>>>> On Wed, Sep 10, 2014 at 10:42 PM, Maxim Solodovnik <
>>>>> solomax...@gmail.com> wrote:
>>>>>
>>>>>> can you check IE without proxy?
>>>>>> can you check JS console in IE (F12 if I'm not mistaken)
>>>>>> It seems jquery and/or some CSS files were not loaded (maybe because
>>>>>> of proxy)
>>>>>>
>>>>>> On 11 September 2014 00:27, William Overstreet <
>>>>>> william.ab.overstr...@gmail.com> wrote:
>>>>>>
>>>>>>> Trying to use openmeetings internally on our lan. I'm running into
>>>>>>> the issue of only internet explorer is refusing work. all the other
>>>>>>> browsers have no issues, reguardless of the OS. The login screen looks
>>>>>>> normal, post login looks like http://i.imgur.com/nwhGX88.png , and
>>>>>>> if I try to join straight to a meeting, all I get is that swirling icon 
>>>>>>> in
>>>>>>> the middle of the screen, the one before the loading bar appears.
>>>>>>>
>>>>>>> The network is stuck behind a http proxy.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> WBR
>>>>>> Maxim aka solomax
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>>>
>>>
>>
>
>
> --
> WBR
> Maxim aka solomax
>

Reply via email to