I am using Views 7.x-3.0-alpha1.

Problem with text areas:
When inserting a "Global: Text area" view Header, the actual text area box is unclickable and unusable.
Once this text area is available and I click update or remove buttons, the javascript will seemingly crash by thowing me to some white screen with some gibberish text on one line.

This happens on any text format including formats where I have no text editors assigned to them.
As soon as I disable the wysiwyg module, I can then properly edit and use this text area.

Problem with check boxes:
The filter "Node: Published" is supposed to have a Yes/No checkbox.
When wysiwyg is enabled, this checkbox is missing.
When wysiwyg is disabled, this checkbox is available.

Comments

twod’s picture

I can't reproduce the checkbox problem, I see two Yes/No radiobuttons with Views 7.x-3.0-alpha1 and CTools 7.x-1.0-alpha2.

I can partially reproduce the textarea problem though I didn't get an error, there was just no editor.
The white screen with gibberish text was most likely the JSON response from View's AJAX request that did not get intercepted properly. When that happens the form was submitted in the foreground instead of the background so the entire page was reloaded and now shows just the code response. This can happen if script execution is halted due to some error or unfortunate timing coincidences.

There's no editor because Wysiwyg can not yet handle being loaded via AJAX. When the form is updated to include a format-enabled textarea which has attached editors, Drupal should tell Wysiwyg module's scripts to attach its behaviors to those elements. But since Wysiwyg or the editor libraries weren't included when the page was first loaded the scripts aren't there to handle that request.
Fixing this will require changes to all of Wysiwyg's code so it'll take some time.
There's an older issue about this already so I'll mark this one a duplicate of #356480: Lazy-load editors.

twod’s picture

Status: Active » Closed (duplicate)

Let's try that again...