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

Fri Feb 26 21:59:54 UTC 2016

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

Ticket URL: https://bugs.horde.org/ticket/14267
------------------------------------------------------------------------------
  Ticket             | 14267
  Updated By         | horde-support at inetspec.com
  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             |
------------------------------------------------------------------------------

horde-support at inetspec.com (2016-02-26 21:59) wrote:

> Cannot reproduce. I can reply/forward/redirect to any email from  
> both IE11 (11.103.10586.0) and Edge on Windows 10.
>
> Are you using JS caching? If so, try it with caching turned off and  
> then with it on, but after clearing the cache files.

Alright,

IE is a slightly different version, but we do not really have control  
over the version that we use as it is based on administrative updates.  
  The version on this machine is currently 11.0.10240.16683.

I cleared the cache from IE and tried again without any change in results.

I then logged out, cleared the IE cache, restarted the browser, and  
logged into "basic" mode.  Still gives a number of different errors in  
the console, but no fatal ones.  I was able to send a test email in  
Basic mode.

I then repeated those steps for Dynamic mode.  After verifying that I  
had no cached .js files and restarting the browser, I logged in the  
same user as Dynamic mode.  I received the same results as the  
original ticket.

At any rate, I see no evidence of cached .js files on the client side.

Is "JS caching" something that is configured by default in Horde or  
IMP?  If so, how is that default changed?  Again, at any rate, I have  
not been able to find any evidence of cached files in the Horde  
installation or the HTTP server, so this is probably a 'moot' point

More directly, looking at the call stack and the trace, the difference  
in handling between IE and other browsers occurs at lines 1408-1414 in  
the ./imp/js/compose-dimp.js file.  It looks like that call is  
directly related to the resulting error.  It is interesting that it  
mentions "bubble" in the comment.

A window object is being passed into prototype.js but the window does  
not have an 'observe' method.  This would normally be a 'document'  
object which does have an 'observe' method.

I temporarily edited the ./imp/js/compose-dimp.js file to allow IE to  
be treated the same an any other browser, then cleared the browser  
cache, and logged in again using Dynamic mode.  I was then able to  
begin a new message and successfully send.

1408  /* Attach event handlers. */
1409  if (Prototype.Browser.IE) {
1410      // IE doesn't bubble change events.
1411      // $('identity', 'upload').invoke('observe', 'change',  
this.changeHandler.bindAsEventListener(this));
  added->  document.observe('change',  
this.changeHandler.bindAsEventListener(this));
1412      } else {
1413      document.observe('change',  
this.changeHandler.bindAsEventListener(this));
1414      }

Apparently, on line 1411 the expression "('identity', 'upload')"  
resolves to the window, and not the document (at least in IE11).

I cannot find any specific revision information inside the  
compose-dimp.js file, however, it's timestamp matches all of the other  
.js files for IMP from the date of installation which was Feb 5. (at  
least it did until I edited the file to perform the test)

The prototype.js file shows: Prototype JavaScript framework, version  
1.7.2, and a file date of Feb 23 (which was the last time that I did a  
pear update).  However, this problem existed previously, which is why  
I did the pear update.  There is a newer (1.7.3) prototype.js  
available from the upstream.  I would be happy to test with that.

However, it looks like the root of the problem is the 'if' decision  
made in the compose-dimp.js file at line 1409.

Likely causes may be:
  - differing user-agent strings / features reported from various  
versions of IE
  - differing DOM structures in various versions of IE
  - JScript interpretation of Prototype JS at various versions

The browser on this machine is currently reporting:
"Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko"

Also, I would suggest that if you cannot reproduce this problem, then  
at line 1409, your browser is not being detected as IE by the  
prototype.js code.  That would explain the difference in results.  If  
for any reason your browser is detected as "Mozilla", then your  
browser skips around the code that crashes other IE browsers (but  
perhaps not all).  As it is, in our local case, the browsers are  
definitely executing line 1411 and not line 1413 despite the newer  
user agent string.

For what it's worth, I think this IE detection issue is still open on  
GitHub at the time of this writing...
Ref: https://github.com/sstephenson/prototype/issues/120

So, what does :: if (Prototype.Browser.IE) :: really mean?  I am not  
conviced that it means anything related to whether a browser supports  
"bubble" or "capture" for events, at least not in today's world.   
Should that handling call really be based on that specific boolean  
flag in Prototype JS?

I believe that this warrants a closer look into how the calls are made  
from Horde / IMP code into supporting libraries, especially when they  
are done differently based on a decision about which User Agent is in  
use.

Is there a better way to address the 'document.observe' method with a  
more cross browser compatible statement, or is it just a browser  
detection problem?

It may be necessary to further detect versions and capabilities when  
IE is the User Agent in order to avoid filing IE11 into the "do it  
differently" column.

Again, very happy to help with more information, and if I was better  
with Prototype JS / Javascript I would even try hacking at a permanent  
solution.  If you are using IE11, then you could try forcing it to run  
line 1411 and see what happens.

Or, is that code even the same in your currently used version of  
compose-dimp.js?