Tickets :: Comment on [#14267] Forward / Reply / New message results in popup "Loading..."

* Your Email Address
* Spam protection	Enter the letters below: . ..__ . . ..__ \ /[__)\| \| \|[ __ \/ \| \\|___\|__\|[_./
Comment	>>> Because this is the first time this has been reported and that code >>> has been in place for years. >> >> Interesting, not sure why you think that, here is a list, >> other than this one, newest to oldest: >> https://bugs.horde.org/ticket/13313 >> https://bugs.horde.org/ticket/13079 >> https://bugs.horde.org/ticket/12916 >> https://bugs.horde.org/ticket/10187 >> https://bugs.horde.org/ticket/8740 > > Just because all of those tickets involve the compose window does not > mean they are the same issue. Some of those bug reports are ancient, > some involve only Macs (no clue how that related to IE detection), > and none of them are related to the same code your bug report > suggested was the issue. > >>> Well, did you actually test that the event handler that is being >>> attached in that line actually works correctly and catches the events >>> it is intended to or are you just stating that after the page loaded >>> there were no errors? >> >> No, and I did not actually elude to the fact that there were no further >> errors. > > Saying that something " works just fine in IE 11?" led me to believe > that everything was working. If the event handlers that are being > registered do not work, then things are NOT "just fine". > >> I only stated that the compose window did load and was able to >> send a message by allowing the code to believe that it was serving to a >> browser other than IE. >> >> Honestly, I am not even sure what events that I should be checking for >> other than the ability to avoid a fatal error. Care to clue me in what >> you are looking for here? Hovers, email lookups, drag and drop, what? > > My apologies. I assumed a level of familiarity with the javascript in > question since you had such a thorough explanation. It's the 'change' > handler of the 'upload' and 'identity' node...but this is rather moot > anyway, since we know that those are not registered correctly on > certain versions of IE and thus we cannot remove that code as you > suggest. > >>> No one is choosing not to fix anything, but rather haven't yet >>> determined what needs fixing and the best way to fix it so as to not >>> introduce a regression for any other browsers. >> >> Understood. Since we have ruled out caching and IE versions, then we >> should look elsewhere. I would suggest looking at the DOM structure as >> well as the library versions from PEAR. >> >> Can you provide a text/html of a working New Message window popup that >> I can check against the window popup content on my side? > > I can do this when I'm back in my office - you can use the Horde demo > server to find this, as I also tested using this. demo.horde.org > >> Can you provide a PEAR list of libraries w/ versions on the server that >> you are using so that I can also compare against our installation? > > Tested on a fresh install of current stable releases as well on > current Git master code, and the Horde demo server. > >>> Since we cannot reproduce this on our >>> side we need more information. As you state, many people use IE and >>> so far this is the one and only report of this. >> >> See above. > > Again, none of those were related to the same code you are talking about. > > >>> Additionally, I have also tested this on IE 11.0.9600.17351 - with >>> the same results. >> >> Well that is good to know. I have actually seen the same problem on >> other different platforms since the original post and am not convinced >> the problem is limited to IE at all. >> >> It seems to me that with the number of un-resolved reports of similar >> problems and the consistency of the errors in specific installations >> that, the problem may actually be related to: >> >> 1. an un-documented dependency in a PEAR library, or >> 2. an un-tested dependency for a later version of a PEAR library > > Unlikely since this would lead to fatal PHP errors. > >> It may even be something that has developed over a period of time as >> browsers have evolved to treat various DOMs differently. > > Of course - but we can't neglect the older browsers that are still > supported in the same major version. > >> I have looked at the installation logs from the server that we are >> using on this installation. I do not see any 'required' libraries >> missing and there are no complaints about versioning that I can see. >> >> With specific regard to IE11, it looks much more like Mozilla than it >> does the old IE. Similarly with Edge, it looks much more like >> WebKit than it does anything else. Therefore, in those two cases, >> the calls that are more appropriate for more modern browsers would >> make more sense than the calls for say, IE7 or IE8 > > Agreed - but as demonstrated the IE detection still detect these as IE. > >> Furthermore, it may actually be the DOM structure that is confusing >> the browser on the client side, and there are many factors that >> adjust and change that structure for the dynamic views, especially >> when the dependencies on various PEAR libraries are taken into >> account. >> >> If we can identify where the base problem is introduced and find an >> applicable solution, we will probably solve all of the outstanding >> tickets related to this compose window popup problem. >> > > Since your very first error line reads: > > > Line 2092 InvalidCharacter > > It sounds to me like everything else afterwards is a side effect of this.
Attachment
Watch this ticket

Saved Queries