ZF-11315: Zend_Dojo_View_Helper_Editor submit problem with Chrome

Issue Type: Bug Created: 2011-04-22T09:21:54.000+0000 Last Updated: 2011-08-01T11:34:23.000+0000 Status: Resolved Fix version(s): - 1.11.6 (05/May/11)

Reporter: Thomas Deyhle (thomas deyhle) Assignee: Robert Basic (robertbasic) Tags: - Zend_Dojo

  • View_Helper

Related issues: Attachments: - ZF-11315.diff



I create a Editor-Element in a form with the start value "Hello" Then I change this value on the page to "Hello world" and submit the form. Now the server should recive the value "Hello world", but if you try this in chrome I recive always the start value "Hello".

This problem apears only with the Chrome browser. The editor works fine with other browser.

Excample: I create the editor with the id 'comments' then you get the following html:

<pre class="highlight">

Here you can see that the input and the textarea tag have the same name "comments". If you change the name of the textarea from "comments" to "comments-Editor" like the id, then it works fine also in chrome.

In the function editor in Zend_Dojo_View_Helper_Editor you can see, that the textare is bild with the name of the id from the hidden field instead of the id from the textarea:

<pre class="highlight">
$html .= ''
      . $this->view->formTextarea($hiddenId, $value, $attribs)
      . '';

If you change it to

<pre class="highlight">
$html .= ''
      . $this->view->formTextarea($textareaId, $value, $attribs)
      . '';

it will work in chrome.


Posted by Robert Basic (robertbasic) on 2011-04-22T09:56:03.000+0000

Could you please provide the PHP code you're using to create the form/element?

And Chrome's version number and the OS you're using. Thanks!

Posted by Thomas Deyhle (thomas deyhle) on 2011-04-22T11:28:03.000+0000

I simplified it to the basic to show it. I'm using Smarty as template.

here the code

<pre class="highlight"> 
        'tabIndex' => 3,
        'required' => 1,
        'height' => '200px'
    array (
        'style' => 'width: 500px;'

and here the templete

<pre class="highlight">


Im using: Chrome 10.0.648.205 Appears on my local dev with win 7 an on my productiv system with openSuse

Posted by Robert Basic (robertbasic) on 2011-04-22T12:35:37.000+0000

I can't reproduce the issue with zf 1.11.5 and Dojo 1.5.0 or Dojo 1.6.0 loaded from Google's CDN.

Chrome 10.0.648.205 on Ubuntu.

What versions of ZF and Dojo are you using?

Could you please try the same, but with using Zend_View and not Smarty?


Posted by Thomas Deyhle (thomas deyhle) on 2011-04-23T14:29:31.000+0000

I made a big mistake in testig. Sorry. The content of my testpage is loaded by dojo.

It seems that when there are 2 tags with the same name, in this case the input and textarea tag, the browser should return the content of the firt tag he can find. This works fine on normal loaded pages in every browser I testet.

If the content of the page is loaded per ajax it seems to be different in Chrome. If I look on the elements in debuging in Chrome, the order and everything else is in the same way as at normal loaded pages. But the result is different.

I don't know why there are the same names for these two tags. If you have a look at the code, there is a separate definition for the name of the textarea in $textareaName and for the id in $textareaId. But the $textareaName will be never used. The definition of $textareaName is "name[Editor]" instead of the "name-Editor" like in the ID. I think it isn't a good solution to use an array at this place, so this could be the reason that someone change from $this->view->formTextarea($textareaName, $value, $attribs) to $this->view->formTextarea($hiddenId, $value, $attribs) what is a working solution but I thing isn't totaly correct, because of the double use of the same name in two tags.

I'm using zf 1.11.5 and tested with Dojo 1.5.0 and Dojo 1.6.0 and can reproduce it with a dojo dialog which load the form with the editor in it.

Sorry to cause inconvenience.

Posted by Robert Basic (robertbasic) on 2011-04-25T15:37:22.000+0000

Think I narrowed down the problem, will try to explain it as better as I can what's going on.

When Zend_Dojo_Form_Element_Editor is loaded "normally", e.g. is just simply rendered to the view, when submitting the form with that Editor every browser takes note about the noscript tag around the textarea and doesn't submit that value, only the value from the hidden input field.

But! When loading a Zend_Dojo_Form via ajax into the current view and submitting that form, looks like Chrome is submitting the textarea value from within the noscript tag too, whereas Firefox is not doing that (not sure about IE/Safari/Opera). Thus we end up with submitting 2 elements with the same name in Chrome and as the hidden input tag is first by order in the DOM, Chrome picks up that value.

Poking around with the code, will try to come up with a fix.

Posted by Robert Basic (robertbasic) on 2011-04-25T16:15:16.000+0000

Patch for this issue.

The fix is easy, but ugly. Reordered how the Editor elements are generated: the textarea in the noscript tag should be rendered before the hidden input tag so that when doing a submit, Chrome picks up the value from the textarea first if noscript is in effect. Also, the div for the dijit should be rendered before the textarea or the editor won't be created in Chrome due to a dojo warning.

I didn't rename the textarea tag name as suggested by the reporter because then upon submitting we'd have 2 different names in the POST data, which is again cumbersome.

I'd really appreciate some feedback on this.

Posted by Thomas Deyhle (thomas deyhle) on 2011-04-25T19:14:39.000+0000

I've tested in the way you recommended and it works in the following browsers on Win7:
IE 8.0.7600, FF 3.6.16, Opera 11.10, Chrome 10.0.648, Safari 5.0.5

Posted by Matthew Weier O'Phinney (matthew) on 2011-05-02T20:14:56.000+0000

Reviewed the patch -- looked straight-forward, and based on feedback from functional testers, appropriate. I've added a unit test to ensure that the is generated following the

, which effectively unit tests the functionality from the server-side. Patch applied to trunk and 1.11 release branch.

Posted by Robert Basic (robertbasic) on 2011-08-01T11:34:23.000+0000

Pull request for porting the patch in ZF2 is sent:

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.