48201 2010-10-23 21:43:03 -0700 REGRESSION Zimbra email compose is broken with the HTML5 parser 2010-10-28 13:14:00 -0700 1 1 1 Unclassified WebKit Evangelism 528+ (Nightly build) All All RESOLVED FIXED Regression P2 Normal --- 41115 1 mihaip webkit-unassigned abarth eric oldest_to_newest 298517 0 mihaip 2010-10-23 21:43:03 -0700 To reproduce: 1. Go to http://testzimbra.com/ 2. Log in with username "zm1023yyxhm" and password "hvtpki" 3. Wait for all the UI to load 4. Click on the "New" button under the "Mail" tab to bring up a compose window Expected result: 1. Compose window that you can type in Actual result: 1. No editable area for the body of the email This appears to be intermittent, so you may need to try it a few times to trigger it. Having an empty cache seems to make it more likely to happen. Using nightly builds I narrowed it down to the range r64727 to r64636. http://trac.webkit.org/changeset/64712, which enabled the HTML5 tree builder, was in that range. I verified that that particular change was responsible. This is a beast of an app to reduce, but as far as I can tell, there's some sort of race condition with the body compose iframe. It has a src of http://demo2.zimbra.com/zimbra/public/blank.html. With the HTML5 parser change, I often see the compose area flash before it's replaced by the empty blank.html frame. Without the HTML5 change, "Failed to load resource: cancelled" message in the console about the blank.html frame. I'm guessing the app is registering an onload handler and enabling designMode on the frame and filling it with the new email template, and implicitly disabling the load of the blank.html source. That last part is no longer happening with the HTML5 parser, which is why blank.html is clobbering the compose area. With things like bug 43423 I see that the HTML5 parser is affecting how events are fired for frames, but I don't know much else about this. 298524 1 abarth 2010-10-23 22:01:50 -0700 Any chance this is related to Bug 43328 ? 298527 2 mihaip 2010-10-23 22:08:02 -0700 It looks like this is the source of the compose mode editor, and specifically the iframe initialization: http://google.com/codesearch/p?hl=en#l5SZa4ix2r4/Ajax/WebRoot/js/dwt/widgets/DwtHtmlEditor.js&q=DwtHtmlEditor&l=739 The code could definitely be race-y (there's a 50ms timeout after adding the iframe before trying to initialize it, etc.) 298529 3 mihaip 2010-10-23 22:08:51 -0700 (In reply to comment #1) > Any chance this is related to Bug 43328 ? That regressed with the HTML5 lexer (r61234), this didn't regress till the HTML5 tree builder (r64712), so I don't think they're related. 298530 4 abarth 2010-10-23 22:10:51 -0700 Interesting. Most of the timing related changes came in with the tokenizer. 299325 5 abarth 2010-10-26 00:42:24 -0700 The compose window is begin blown away when the first data come back from the network for blank.html. Clearing the cache makes the bug more likely to occur because it delays the network load. 299333 6 abarth 2010-10-26 01:15:14 -0700 In Safari 5, I believe Zimbra is calling document.open or document.write on the iframe, which cancels the load. However, in debugging TOT, I see that it's not calling those functions. Instead, it's using innerHTML to set the content of the frame (which, of course, does not cancel the load). The reason I believe it's calling implicitOpen in some form is that the contentDocument.URL of the iframe in Safari 5 is "http://testzimbra.com/". The likely way for that to open is because the URL is inherited via implicitOpen. 299340 7 abarth 2010-10-26 01:28:52 -0700 Look like the code on the live site is slightly different than the code on codesearch: DwtHtmlEditor.prototype._finishHtmlModeInit = function () { var a = this._getIframeDoc(); try { if (AjxEnv.isSafari && a.body == null) { a.open(); a.write("<html><head></head><body></body></html>"); a.close() } } catch (t) { return } if (AjxEnv.isGeckoBased) { a.open(); a.write(DwtHtmlEditor.INIT_HTML); a.close() } function e(i) { this._enableDesignMode(i); this._setContentOnTimer(); this._updateState(); this._htmlModeInited = true; this._registerEditorEventHandlers(document.getElementById(this._iFrameId), i) } if (AjxEnv.isIE) { setTimeout(AjxCallback.simpleClosure(e, this, a), DwtHtmlEditor._INITDELAY) } else { e.call(this, a) } }; 299342 8 abarth 2010-10-26 01:34:45 -0700 > if (AjxEnv.isSafari && a.body == null) { I suspect the difference is that in the old tree builder a.body was null at this program point but it's non-null now, which means the site no longer calls document.open() and it no longer cancels the load. IMHO, this is an evangelism issue. Life would be much better if they sent us down the Gecko codepath in this function. 301262 9 abarth 2010-10-28 13:14:00 -0700 The Zimbra folks have kindly fixed the issue on their end.