plainblack.com
Username Password
search
Community Support
Wiki
Forums
Report A Bug
Request Features
WebGUI 8
WebGUI TV
Add-ons and Plug-ins
Service Providers
webGUI in the news
Karma
API Docs
the people behind wg
webgui worldwide
Mascot
wallpapers
Stats
powered by icons
Bookmark and Share
View All Tickets
Cursor disappears in non-Rich Editor window  (#9777)
Issue

Problem: When editing the description field of an asset with Rich Editor disabled, both the cursor and any text selections are invisible!

Most people probably use the Rich Editor for managing the Description field of their assets, but we have found that the Rich Editor's HTML editor pop-up window sometimes modifies the code when inserting it back into the WYSIWYG interface, making it impossible to apply some types of HTML (even though the HTML is valid!). (Perhaps this is another bug to report...) The only way we've found around this problem so far is to enable "Ask user about using rich edit?" in the Content Manager's Rich Edit configuration. When enabled, you are presented with a popup box asking if you want to use Rich Edit the first time you click on the Description form field. If you opt out of using Rich Editor, you are presented with a basic HTML text area form field and raw HTML code.

After our recent upgrade from 7.3.22 to 7.5.38, we discovered that the non-Rich Edit window loses any ability to see your cursor when you click on the content, and highlighting for selected content also does not appear. One of our content managers discovered that if you click outside of the Description box then back again, the cursor appears as normal.

I have checked the problem on a VM running 7.6.12, and the problem appears there as well.

Of the web browsers that I have tested, this appears limited to Firefox 3; it does not appear to be a problem for IE 6 or 7.

Solution Summary
Redid the way that the enable is done.  When "Ask user" is enabled, the editor is initially off, and there's a link below the textarea to enable/disable it.
Comments
bartjol
0
2/23/2009 9:21 am 		This is a reaction to the first part, where html is erased. You might wanna check the security settings of the rich editor (which can be found in Root->Import Node->Rich edit). There is a field for valid html. If this is not *[*] but filled with specific html tags, you can change that setting (I would recommend to add a rich editor and edit the new one)
bartjol
0
2/23/2009 9:46 am 		On the second part, I experience that the cursor is not visible, but works as normal. I'm not sure whether this was what you intended, but if, I confirm the behaviour. Including the clicking out of the box part.

And I saw the following errors:

line 22 column 9 - Warning: <script> attribute "text" has invalid value "text/javascript"
line 22 column 9 - Warning: <script> proprietary attribute "text"
line 22 column 9 - Warning: <script> inserting "type" attribute
line 72 column 2 - Warning: <form> attribute value "POST" must be lower case for XHTML
line 94 column 41 - Warning: <textarea> proprietary attribute "mce_editable"
UMN_law
0
2/23/2009 9:56 am 		Thanks for the first suggestion, but the HTML is being changed DESPITE the fact that we still have the valid HTML setting at the default "*[*]" Even with this setting, the Rich Editor was still changing the HTML when inserted from the pop-up HTML editor back into the Rich Editor interface. Here's a couple examples off the top of my head:

I recently wanted to use an article (with a totally blank template) to insert a span into another article via the AssetProxy macro. (I needed to use an article, and not a snippet, though I can't recall the reason why.) The Rich Editor was insisting on wrapping the span in a paragraph tag.

The other example was with the "background" CSS declaration that can be used to set a number of properties all at once. This was from longer ago, so I can't dredge the specifics out of memory, but I do seem to recall that it was the background-image URL component that was being mangled when inserted back into the Rich Editor. I could get the effect I wanted only by setting all the background properties with their separate declarations, which was a pain and a lot of extra code. That was the point at which I enabled the Rich Edit prompt, so that I could bypass the problem caused by the Rich Editor all together.
UMN_law
0
2/23/2009 10:10 am 		Regarding your second reply, yes, the cursor still works; the problem is that you can't see it. It's more of a problem when you're trying to select large areas of text, especially if the selected text spans more than you can see in the window extent. The only point at which you can confirm that you selected what you intended to is when you then do something to the selection, such as change formatting, delete, etc. It's because the tool still works that I categorized the problem as Minor.

Thanks for your observations on the errors. What are you using to catch them? I have the Web Developer plugin for Firefox, which catches "Unknown property 'zoom'" for /extras/resize.css and "Error in parsing value for property 'filter'" and similar errors from the YUI libraries. But I see these sorts of errors on every page when admin is turned on.

...however, now that I look at it in more detail, I also see an "Error in parsing value for property 'cursor' for /extras/yui/build/container/assets/container.css (line 292). I wonder if that's related.
bartjol
0
2/23/2009 11:03 am 		It is a HTML validator plug in which gave me the errors (warnings), but your latest paragraph seems to reveal a tip of the veil.

In conf files of the rich editor there are some limitations for HTML tags and attributes, allthough, I don't know them from the top of my head.
but the rest I should take some more time for, than I have left today.
perlDreamer
0
6/27/2009 10:35 pm 		Note, in newer versions of TinyMCE the "ask" option has been completely removed.  There are no longer any built-in option to prompt the user to see if they want to use the rich editor, or not, instead, they recommend something like this:

http://tinymce.moxiecode.com/examples/example_01.php
perlDreamer
0
8/6/2009 4:14 pm 		UMN_law: I need to know which version of Firefox on which platform is giving you this problem.  I tried duplicating this with FF 3.0.13 on Linux, and its working fine.
perlDreamer
0
8/6/2009 4:26 pm 		Tested on 3.0.5 on CentOS with no problems
perlDreamer
0
8/6/2009 6:06 pm 		On 3.0.5 on Vista, the bug shows up.  Trying latest Firefox next.
perlDreamer
0
8/6/2009 6:11 pm 		Also, on FF 3.0.13, the latest 3.0
UMN_law
0
8/6/2009 10:06 pm 		We're pretty much strictly a PC operation, and all my testing was on XP.

I've confirmed the behavior in the PC version of Firefox 3.0.13 and 3.5.2. It does NOT show up with IE 6.0 or 7.0. (Haven't set up 8.0 yet).

I've also confirmed with all four browsers mentioned above that the same patterns are observed with sites running WebGUI 7.5.38, and 7.7.16.
UMN_law
0
8/6/2009 10:17 pm 		I've also just now downloaded the latest Google Chrome (2.0, on XP) and the bug does NOT appear in this browser. So far, I've only seen it in Firefox.
perlDreamer
0
8/7/2009 3:42 pm 		Fixed in 7.6.35 and 7.7.17
Resolved by perlDreamer
Details
Ticket Status Resolved  
Rating0.0 
Submitted ByUMN_law 
Date Submitted2009-02-20 
Assigned To unassigned  
Date Assigned2010-09-02 
Assigned By 
Severity Minor (annoying, but not harmful)  
What's the bug in? WebGUI Stable  
WebGUI / WRE Version WG 7.5.38, 7.6.12; WRE 0.8.5  
URLbugs/tracker/9777
Keywords
Ticket History
8/7/2009
3:42 PM 		Resolved perlDreamer
2/20/2009
3:44 PM 		Ticket created UMN_law
© 2010 Plain Black Corporation | All Rights Reserved