Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#2767 Compose fail refresh after send Mac

pending
nobody
Compose (426)
5
2011-11-23
2011-09-01
dragonmac
No

The issue happens in Firefox, Safari, and Chrome for the Mac only. It has been reproduced in Mac OS 10.4, 10.5, 10.6 not Lion yet. SquirrelMail version is 1.4.22 running Mac OSX server 10.4.11 with updates to PHP version 5.2.4 OK. Cyrus IMAP4 v2.2.12-OS X 10.4.0 server.
This issue does not occur in SquirrelMail 1.4.21.

When a user composes a mail they click the send button. After that the mail is sent and the message does go to the sent mail folder. The only thing is that the right frame does not refresh to the inbox. It stays on the compose mail in the right frame and the user can click the send button many time and they do thinking the mail is not sent.
There is also I believe a related issue that has to do with the left bar not refreshing correctly. An example of this is when the "purge" link is pressed when mail is in the trash. One you click it it does work but does not refresh the bar and you can click it several time.
PC users appear unaffected at this point.
I see no server side errors but I see user side browser errors.

Failed to load resource: Operation could not be completed. (NSURLErrorDomain error -999.) :16080/webmail/src/right_main.php?mailbox=INBOX&sort=0&startMessage=1

Security Error: Content at http://xxx.mydomain.net:16080/webmail/src/right_main.php?mailbox=INBOX&sort=0&startMessage=1 may not load data from http://xxx.mydomain.net/webmail/src/webmail.php.

Unmatched </embed> encountered. Ignoring tag. left_main.php:73

I have since reverted to 1.4.21 and all seems well.

Discussion

  • dragonmac
    dragonmac
    2011-11-23

    Can someone respond to this and let me know if you need more information, can you reproduce this or are you aware and working on this?

     
  • My sincerest apologies for not responding sooner - you caught us at a busy time.

    Thanks for the detailed report. I cannot reproduce this issue, but it looks to me like the security policy error is probably caused by the addition of the anti-clickjacking "X-Frame-Options" header.

    You should try using version 1.4.22 and commenting out line 31 of functions/page_header.php. If that fixes it, you'll probably want to address what looks like your use of a proxy server (?) and how the browsers/OS are choking on that in this context.

    You should ask if it really is a security violation to the SAME ORIGIN policy to load content from a different port at the same domain. I imagine that's a fuzzy area.

    You may be able to avoid this issue by setting $sq_ignore_http_x_forwarded_headers to boolean TRUE in config/config_local.php. If that doesn't help, let us know, but either way, I'd encourage you to investigate the above matters BEFORE making this change and reporting the problem to your OS/browser vendors so they can take a look at the issue.

     
    • status: open --> pending