I'll commit the changes into 3.0 and 3.1 branches and will start new SNAPSHOT build can you please check?
On 16 September 2014 22:08, William Overstreet < william.ab.overstr...@gmail.com> wrote: > 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 >> > > -- WBR Maxim aka solomax
