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

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://bugs.horde.org/ticket/14267
------------------------------------------------------------------------------
  Ticket             | 14267
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | Forward / Reply / New message results in popup
                     | "Loading..."
  Queue              | IMP
  Version            | 6.2.12
  Type               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2016-03-14 20:33) wrote:

>> 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.