Custom Query
Results (501 - 600 of 2646)
Ticket | Summary | Keywords | Owner | Type | Status | Priority | |||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
#2311 | IE: Dialogs are broken with server side samples | Confirmed IE Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
This is quite a strange bug. The dialogs are broken with server side samples, like ASP or PHP, since [2094]. The HTML samples are ok though. |
||||||||||||||||||||||||||||||||
#2314 | Traditional and Simplified Chinese translations for Blockquote are mixed up | Confirmed Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
In Simplified Chinese translation file editor/lang/zh-cn.js, the Blockquote entry reads: Blockquote : "引用文字", But that is actually Traditional Chinese. Similarly, the Traditional Chinese translation file has the Simplified Chinese translation of Blockquote. This is not a too serious defect however because most Chinese users can understand both versions, it just feels strange. The bug was discovered when I was working on #2234. |
||||||||||||||||||||||||||||||||
#2316 | Sample posted data page should have the table width at 100% | Confirmed Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
If small data is posted by the editor, the posted data table shrinks to fit it. It should be instead always at 100% width. |
||||||||||||||||||||||||||||||||
#2320 | FF3: Find/Replace scrolls the entire page | Confirmed Firefox3 IE Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Because the Find/Replace code uses the "scrollIntoView" function, the entire page gets scrolled when highlighting the found elements. This is the same problem we had with #2279 and #2319, so maybe the same solution used there can be used here too. |
||||||||||||||||||||||||||||||||
#2321 | FF3: FCK.InsertElement scrolls the entire page | Confirmed Firefox3 Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Because the InsertElement code uses the "scrollIntoView" function, the entire page gets scrolled when inserting new block elements. This is the same problem we had with #2279 and #2319, so maybe the same solution used there can be used here too. |
||||||||||||||||||||||||||||||||
#2322 | Fit window command resets caret position | Confirmed IE Firefox Safari Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
To reproduce the bug:
Interestingly, the bug does not occur in Opera. |
||||||||||||||||||||||||||||||||
#2323 | Show blocks command scrolls selection out of visible area. | Confirmed Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
To reproduce the bug:
|
||||||||||||||||||||||||||||||||
#2327 | fckpaste.html - escaping HTML inside Javascript (like #2056) | Confirmed Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
I am not allowed to reopen ticket #2056, so here is my report. The problem is still present in "editor/dialog/fck_paste.html" line 67 : </iframe> has to be replaced with <\/iframe> |
||||||||||||||||||||||||||||||||
#2333 | '>' replace with '>' on safari and Opera | Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
I found this bug on my google summer of code 2008 period. when I use fckeditor as moinmoin wiki's gui editor, sometimes document parser throw exception. When I insert '>' to editor area it change to '>' after FCKDataProcessor.ConvertToDataFormat executed. as I found, this behavior only happend on apple safari(3.1.1 on window xp. I couldn't test any other safari browser). You can easily produce this bug using fckeditor's testcase.
attached file is testcase what I use and screeanshot of result.
|
||||||||||||||||||||||||||||||||
#2334 | [IE] XHTML namespace support broken | Confirmed IE | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
I have the following content: <p xmlns="http://www.w3.org/1999/xhtml">this is interesting</p> On Firefox 3 this shows in the source as: <p>this is interesting</p> So FCKeditor has stripped out the xmlns declaration. OK. But then I create an editor on IE7 with the same comment. The source shows: <p xmlns="http://www.w3.org/1999/xhtml">this is interesting</p> I then add the <em> tag around "is". This results in: <p xmlns="http://www.w3.org/1999/xhtml">this <em xmlns="">is</em> interesting</p> This breaks my content. It won't even show up in the browser, as FCKeditor has taken <em> out of the XHTML namespace. |
||||||||||||||||||||||||||||||||
#2336 | [IE] Second dialog box causes loss of position context | IE | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Using IE7, FCKEditor 2.6.2 In editor scroll down to a table in page. Right-click and select 'Cell Properties'. If select an attribute like 'word wrap' and click OK then remain with cell that I started off with. However, if I select 'Background color' or 'Border color', which launches a second dialog box, then the content in the editor jumps to the top of the page and I no longer return to the cell that I was working on. |
||||||||||||||||||||||||||||||||
#2342 | Horizontal Rule id get removed on IE7 | IE | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
If I switch to source view (IE 7) and type: <hr id="test" width="50%" /> then switch back to WYSIWYG and then back to source, the code gets changed to: <hr width="50%" /> on Firefox 3.0 it leaves the id intact. |
||||||||||||||||||||||||||||||||
#2347 | IE: The "id" attribute of <hr> elements get lost | Confirmed IE | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Pasting the following code in the source: <hr id="test" /> Switching to WYSIWYG and back to source gives us: <hr /> Confirmed with IE. Ok with Firefox. |
||||||||||||||||||||||||||||||||
#2349 | [IE] Dialog system is broken with rtl | Confirmed IE Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
When using RTL language on IE6, the new dialog system is broken (there are two scroll bars, and some of the dialog is missing).
The image attached is using the nightly build, with IE6 and 'he' in the accept_language. FCKConfig.AutoDetectLanguage = false ; FCKConfig.DefaultLanguage = 'he' ; in the fckconfig.js file. |
||||||||||||||||||||||||||||||||
#2356 | IE7 Access Denied - Local Filesystem | Confirmed IE7 Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Problem: Opening any of the html sample pages of FCKEditor from the filesystem in IE7 gives an "Access Denied" error coming from file fckeditor\editor\js\fckeditorcode_ie.js on line 62 with the code: "B.open("GET",A,false);". This has been resolved by me in the post: http://www.fckeditor.net/forums/viewtopic.php?f=6&t=10424 Basically the native IE7 XmlHttpRequest Object appears to not allow requests on the filesystem. Here is the offending code causing the issues: (file fckeditor\editor\_source\internals\fcktools_ie.js) FCKTools.CreateXmlObject = function( object ) {
} |
||||||||||||||||||||||||||||||||
#2363 | IE7 Local Filesystem Permission Denied | IE Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
This error occurs when loading a document into the fckeditor when running the editor from the filesystem. I am noticing that this error only occurs with very large files. I have a 288 KB html file (which unfortunately I cannot share) that causes this error to appear. Smaller files open in the editor just fine however. I am setting the text of this file using the function
where the html value passed in has the contents of the body of the page to be edited. I cannot reproduce this error on the demo or on the latest demo. I tried to reproduce it by opening the source view, pasting in my code, and going back to the wysiwyg view. I have isolated the problem (when it occurs for me) to the fckeditor/editor/_source/internals/fckdocumentprocessor.js file. Here are my changes to get it to work properly for me. (starts around line 145)
I just commented out the logic that was happening. For whatever reason access to the doc variable was denied. Trying to access any variable inside the doc variable causes a permission denied error. |
||||||||||||||||||||||||||||||||
#2367 | IE: List padding may cause list command errors | IE | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
When applying "padding" and "margin" styles to list elements, IE may "expand" them, making it possible to place the caret "after" sub-lists in nested lists. Other browsers don't make it possible. The problem is that this uncommon caret position breaks the list commands. Steps to Reproduce
<style type="text/css"> ol { padding-bottom: 20px; } </style> <ol> <li>Item 1 <ol> <li>Item 1.1</li> </ol> </li> </ol> <p> Some text. </p>
A JavaScript error will be thrown and nothing else happens. |
||||||||||||||||||||||||||||||||
#2368 | IE: Protected source for comments is broken | Confirmed IE Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
The fix for #2263 is breaking source protection in IE SVN nightly. To replicate:
|
||||||||||||||||||||||||||||||||
#2369 | Updated Faroese language file 2008-07-15 | Confirmed Review+ | Task | closed | Normal | ||||||||||||||||||||||||||||
Description |
File fo.js is attached |
||||||||||||||||||||||||||||||||
#2376 | FCKeditor should remember the last selection position when it loses focus in IE. | Confirmed IE Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
IE has a long standing bug in which it allows only a single selection position to exist within a window, no matter how many iframes and different pages are opened inside. This causes an annoying problem with FCK.InsertHtml():
It should be possible to use the onbeforedeactivate event to save the selection position before FCKeditor is defocused. |
||||||||||||||||||||||||||||||||
#2381 | Double Iframes for FCKeditor | Confirmed Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Possibly asked and answered. Sorry I don't have time to download and verify bugs, and I'm not sure what component this even belongs to. We're using Drupal 5.6 with the 5.x-2.2-beta2 module of FCKeditor. What I suspect is that the error is only visible with this combination. What I know is the error is completely avoidable. in fckeditor.js in function FCKeditor.ReplaceTextarea() Add the following code at the very beginning: var oIFrame = document.getElementById(this.InstanceName + '_Frame'); if (!oIFrame) { Then add the following code at the very end: } This protective if-block will prevent any duplicates from be formed, since the code inside that if-block creates the iframe with then name: this.InstanceName + '_Frame'. Yes, it's probably the fault of some other library further up. Shouldn't matter. Code should do the right thing, and duplicate editors is bad. This won't appreciably affect speed of the component, and is a good thing. If I'm reporting this the wrong way, sorry, if I'm reporting to to the wrong place, double my-bad. But there you go. Jeff |
||||||||||||||||||||||||||||||||
#2386 | Patch for function wfSajaxSearchArticleFCKeditor | HasPatch Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
The function searches by default only the NS_MAIN namespace. It does not extract the namespace from search term and thus does not find articles that are not located in NS_MAIN. The below code adds this functionality: function wfSajaxSearchArticleFCKeditor( $term ) {
|
||||||||||||||||||||||||||||||||
#2387 | FF: Bulleted list error with CTRL+A | Confirmed Firefox Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Tested with Firefox/2.0.0.16, in the online demo. With the following source: <div>aaa</div> <div>bbb</div> <div>ccc</div> In editing mode:
A JS error is thrown and the first line of text is deleted. |
||||||||||||||||||||||||||||||||
#2394 | Split Vertically - It blows up | Confirmed IE Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Steps: 1- Add a new 3x3 table. 2- Point your mouse on the last corner cell (3,3). 3- Right click, and choose "Cell / Split Vertically". The error "Invalid Argument" appears. The cell is not splitted. |
||||||||||||||||||||||||||||||||
#2395 | InsertHtml() can prefix an additional annoying blank paragraph with IE | Confirmed IE Pending | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
If content being inserted is not being inserted into a block level element, but itself begins with a block level element (e.g. <p>insertion</p>), then this results in the extra blank prefixed paragraph. Following are lines 165 through 173 (as of 07/19) of the InsertHtml() function in the 'internals/fck_ie.js' file. // Using the following trick, any comment in the beginning of the HTML will // be preserved. html = '<span id="__fakeFCKRemove__" style="display:none;">fakeFCKRemove</span>' + html ; // Insert the HTML. oSel.createRange().pasteHTML( html ) ; // Remove the fake node FCK.EditorDocument.getElementById('__fakeFCKRemove__').removeNode( true ) ; This 'trick' is what I find causing the extra beginning blank paragraph. I suspect that pasteHTML() is making the HTML valid by putting the span inside of a block level element (namely a <p> tag). Then the removal only removes the span thus leaving the extra paragraph. ( <p> </p> ) I'd prefer having to embed a beginning comment in a tag due to omitting this trick [which is what this ends up doing in this case anyway given <!-- comment --><p>insert</p> to get <p><!-- comment --></p><p>insert</p>] than have this paragraph added when inserting a block with no comment. In other words, this 'trick' semi-fixes so few cases (none in my case) with annoying expense for many use cases. If preserving such comments is important, then replacing 'span' with 'p' (or 'div') works in this particular case, but unacceptably breaks inline insertions. Perhaps the appropiate way should be determined by looking at the parent element. I've tried using elements that can be either block or inline elements (e.g. object), but without success. They always get treated like inline elements. (also work like span) So, unfortunately a good solution for this problem isn't as simple as merely changing the tag. |
||||||||||||||||||||||||||||||||
#2396 | SpellerPages can lead to Permission Denied errors with IE | Confirmed IE Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
One set of steps to reproduce with IE7:
You then get Permission Denied error on line 357. This isn't a problem with FF. I've reproduced with IE7 and several FCKeditor versions from SVN back to version 2.4.3. One way to work around it is to replace the SetHTML() [or SetData()] function in 'fck_spellerpages.html' with: oEditor.FCK.Commands.GetCommand('SelectAll').Execute(); oEditor.FCK.InsertHtml(document.getElementById('txtHtml').value); (but with extra prefixed blank paragraph noted by ticket #2395) I have NOT been able to reproduce by using SetData() in a much simpler, but very similar scenario (plugin) that replaces content containing an anchor tag. So, there seems to be more to causing this than just simply using setData() with content containing an anchor tag. |
||||||||||||||||||||||||||||||||
#2400 | Updated Traditional and Simplified Chinese translation files | Review+ | Task | closed | Normal | ||||||||||||||||||||||||||||
#2401 | Croatian language file updates | Confirmed Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
Updated hr.js file |
||||||||||||||||||||||||||||||||
#2402 | Catalan language file updates | Confirmed Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
#2405 | japanese language file updates | Confirmed Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
#2406 | Vietnamese language file updates | Confirmed Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
Completed Vietnamese language file. |
||||||||||||||||||||||||||||||||
#2407 | Applying the div tool from the toolbar to a list screws the list up | Confirmed Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Applying the div tool from the toolbar to a list screws it up. Type and select:
Then apply the div tool. Give it an inline style "border: 1px solid blue;". Result: paragraphs are added with contents of the li items. The list contains only spaces. The paragraphs are wrapped in the new div, but the list is outside the div. tested both ie7 and firefox3 |
||||||||||||||||||||||||||||||||
#2409 | Language updates for Norwegian (no and nb) | Confirmed Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
Updated language files for Norwegian (no) and Norwegian Bokmål (nb). It includes missing translations and corrected incorrect translations. "Nummerert" (numbered) was misspelled (as 'numrert'), and has been fixed. Some of the terms for form elements are incorrect, and I've replaced them with the established Norwegian terms for form elements. All properties (line 134-148) have been changed as they are more correct in Norwegian. The word "Finn" (Find) has been replaced with "Søk" ('search'), as this is what is currently used in nearly all programs with Norwegian interface. Some longer sentences have been rewritten as they were poorly written and I've also made some minor changes in other places. |
||||||||||||||||||||||||||||||||
#2410 | Hindi language file updates for FCKeditor 2.6.3 | Confirmed Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Added a few strings for the Hindi translation. SVN patch attached. |
||||||||||||||||||||||||||||||||
#2412 | InsertHTML inserts at beginning of selection | Confirmed Firefox Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
This bug may be related to Ticket #2376. In FireFox 3 I see InsertHTML append to the beginning of a Selection, instead of replacing the Selection. Using FireFox 3 go through the same steps in ticket #2376. |
||||||||||||||||||||||||||||||||
#2417 | Dutch language file updates | Confirmed Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
Update of the dutch language file |
||||||||||||||||||||||||||||||||
#2420 | Add SaveUndoStep() to SpellerPages | Confirmed Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
After changeset 2286 from ticket #2396, inserting the following line before line 56 of fck_spellerpages.html could restore a feature omitted by the fix. oEditor.FCKUndo.SaveUndoStep() ; |
||||||||||||||||||||||||||||||||
#2422 | Czech language file for FCKeditor 2.6.3 beta | Confirmed Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Czech language file for FCKeditor 2.6.3 beta |
||||||||||||||||||||||||||||||||
#2426 | IE: Switching between two editors with shared toolbar does not work properly | Confirmed IE Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
When using two FCKeditor instances with a shared toolbar, it is not possible to directly switch from one instance to another. One has to click either outside the editors, then on the second instance, or twice on the second instance. To recreate:
When you select the second instance, the toolbar is deactivated, and the cursor remains in the first instance. You have to click twice on the second instance to properly activate it. The fix of #2376 is the cause of the regression. In my view, it would be best to revert that change, since it makes the use of shared toolbar practically impossible. |
||||||||||||||||||||||||||||||||
#2427 | updated hebrew for fckeditor 2.6.3 Beta | Review+ | Task | closed | Normal | ||||||||||||||||||||||||||||
#2428 | French language file updates | Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
French language file update |
||||||||||||||||||||||||||||||||
#2429 | Spanish lang file update | Review+ | Task | closed | Normal | ||||||||||||||||||||||||||||
Description |
patch for updated es.js file |
||||||||||||||||||||||||||||||||
#2430 | Support THEAD in Tables | Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
Take the patch of https://sourceforge.net/tracker/index.php?func=detail&aid=1409409&group_id=75348&atid=543655 review it and update to current version. |
||||||||||||||||||||||||||||||||
#2437 | V3: Environment and browser information | Confirmed V3ProtoBase Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
We should have an object in API that could be used to identify the current browser and special OSs, like Mac. It should be compatible with our Browser Compatibility Specifications. |
||||||||||||||||||||||||||||||||
#2440 | Dutch language file updates | Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Update for Dutch language file of FCKEditor 2.6.3 Fixed 1 spelling error: toetstenbord --> toetsenbord Fixed inconsistencies in referring to the user: the user is now addressed in polite form (best for corporate environment): "u" / "uw" (instead of "je" / "jouw") |
||||||||||||||||||||||||||||||||
#2441 | V3: Samples | Confirmed V3ProtoStruct Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
We must have clear samples that show most of the editor features. These samples are often used as references when integrating the editor in the real world. |
||||||||||||||||||||||||||||||||
#2442 | V3: trunk folders/files structure | Confirmed V3ProtoStruct Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
The CKEditor prototype presents the following folder structure:
Other than the above directories, other basic files are placed in the root:
Also, in the root folder, we'll find all integration files, named "ckeditor.ext". When "building" the development code, several transformations will happen to this structure. The "adapters", "lang", "plugins", "skins" and "themes" folders from _source will have their relative "compiled" versions in the root. The "ckeditor.js" and "ckeditor_basic.js" files will be also created at that point. |
||||||||||||||||||||||||||||||||
#2444 | V3: Utility functions | Confirmed V3ProtoBase Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
The CKEditor prototype defines the CKEDITOR.tools object, which holds several utility functions using all around our code. Function under this object must be totally generic, independent of other objects and classes. |
||||||||||||||||||||||||||||||||
#2445 | V3: Private variable and functions in the code | Confirmed V3ProtoStruct Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
Whenever possible, the CKEditor prototype code defines private stuff inside closures, so the CKEDITOR object and the window scope remain clean. In some cases, specially on classes, there are private things that we to be defined "per instance". There is no way to define those privates on closures, so those kinds of things must be defined as properties in the objects itself. To have a clean code, making also the DOM inspection clearer, a standard has been used in the prototype. All private things are defined under a single property called "_" (underscore). To have an overview of the effect we have with it, just open any of the samples and select the DOM tab in FireBug. Then, navigate through the CKEDITOR object tree. You will find things like CKEDITOR._ and CKEDITOR.plugins._. |
||||||||||||||||||||||||||||||||
#2446 | V3: Event System | Confirmed V3ProtoBase Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
The new event system must be coded, as defined in the Event Driven page in the ODE docs. |
||||||||||||||||||||||||||||||||
#2447 | V3: DOM abstraction | Confirmed V3ProtoBase Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
We have talked about DOM abstraction in the ODE docs. We should have a clear implementation of this layer in our code. |
||||||||||||||||||||||||||||||||
#2448 | V3: XML handling object | Confirmed V3ProtoBase Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
The CKEditor prototype defines the CKEDITOR.xml class in the "core/xml.js" file, which can be used to handle XML data. This class is not used by the core code right now, only by the template system for the samples. |
||||||||||||||||||||||||||||||||
#2449 | V3: Ajax like data requests handling object | Confirmed V3ProtoBase Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
The CKEditor prototype defines the CKEDITOR.ajax class in the "core/ajax.js" file, which can be used to handle loading of data in the Ajax style. This class is not used by the core code right now, only by the template system for the samples. |
||||||||||||||||||||||||||||||||
#2451 | Basque language file update | Confirmed Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
... Basque language file update |
||||||||||||||||||||||||||||||||
#2453 | V3: Code loading | Confirmed V3ProtoCore Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
The code loading must be implemented as described at Loading and Startup in the V3 documentation |
||||||||||||||||||||||||||||||||
#2454 | V3: Instances creation | Confirmed V3ProtoCore Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
The CKEditor prototype implements a few ways to create editor instances. All methods are defined under the CKEDITOR object, and are available in the "basic" code version.
All function return the created editor instance, which can be used to manipulate it, like adding event listeners. |
||||||||||||||||||||||||||||||||
#2456 | V3: Editor instances | Confirmed V3ProtoCore Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
In the CKEditor prototype, an editor instance is represented by the CKEDITOR.editor class, which is defined in two files, "core/editor_basic.js" and "core/editor.js". To create and editor instance, the following information can be passed to the editor class constructor:
In any case, the editor class constructor is not to be called directly by end users. They will be using the functions available at CKEDITOR for that, as explained in #2454. When an instance is create in the page, the following things happen, in this order:
All the above points will be explained in detail in other tickets. |
||||||||||||||||||||||||||||||||
#2457 | V3: Configurations | Confirmed V3ProtoCore Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
In the CKEditor prototype, the CKEDITOR.config object holds all configurations (core/config.js). It means that the default settings will be included in the core code, not anymore in an external file. It will also mean that we'll be able to fully document each setting in the code. Also, not all settings are defined in that file. Each plugin that has custom configurations can extend this object to its needs. See "plugins/toolbar" for an example. When creating an editor instance, the <instance>.config property is created. It is an empty object, which prototype is CKEDITOR.config. It means that additions to CKEDITOR.config will be automatically propagated to all editor instances, still making it possible to override them with custom settings for each instance. Then, for each instance, the <instance>.config.customConfig setting is checked. If defined, the external file is downloaded. That file must define the CKEDITOR.editorConfig function, which overrides configurations in the editor instance. By default, the editor is configured to download the config.js, from the root of the distribution. Once the custom configuration file is downloaded, its CKEDITOR.editorConfig function is "cached". If other editor instances use the same file, it will not be downloaded anymore, and the cached function will be used. Then, the <instance>.config.customConfig is checked again. The above process repeats until no more configuration files are to be downloaded. There are two ways to avoid loading external configuration files. The "core/config.js" file can be edited, setting customConfig to '' (empty). The core code must be packed again at this point. Or, when creating the editor instance, the customConfig configuration can be set to '' (empty) for the instance. This is the only inline setting that is considered beforehand. Finally, once all external files are downloaded, overriding the global settings, the inline settings are merged into the <instance>.config object, overriding any of the previous settings. To summarize:
|
||||||||||||||||||||||||||||||||
#2458 | V3: Plugins | Confirmed V3ProtoCore Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
The CKEditor prototype is strongly based on plugins. The intention is reducing the core code to the minimum, leaving all other features isolated on plugins. It makes it possible to create customized distributions containing only specific sets of features. When the instance is created, all plugins listed in the <instance>.config.plugins setting are downloaded. Each plugin should call the CKEDITOR.plugins.add() function to register its "plugin definition". This definition is an object containing properties, as documented in the "core/plugindefinition.js" file. As soon as all plugins are downloaded, the "beforeInit" and "init" function in their definitions are called, passing the editor instance to them. In this way, each plugin can make instance manipulations. Each plugin is downloaded once, and shared among all instances. But, the "beforeInit" and "init" functions are only called for those instances which have the plugin defined in the settings. The plugins download and caching is managed by the CKEDITOR.resourceManager class (core/resourcemanager.js), which is used also by the theme system, and in the future by the adapters. All plugins are downloaded from the "plugins" folder. The plugin name in the settings must match the plugin folder name. Each plugin must have the plugin.js file defined. It is possible to configure the editor to download plugins from other folders. This can be done inpage, or in the custom configuration file, by calling the CKEDITOR.plugins.addExternal function. For example: CKEDITOR.plugins.addExternal( 'myplugin', '/customplugin/' ); In the above case, if an instance uses the "myplugin" plugin, the "/customplugin/plugin.js" file will be downloaded. Plugins may have dependencies which can be expressed by the "requires" property in their definitions. All required plugins are downloaded and executed. Check the "htmldataprocessor" for an example. |
||||||||||||||||||||||||||||||||
#2459 | V3: Skins | Confirmed V3ProtoCore Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
In the CKEditor prototype, an editor skin is simply a set of CSS files which are loaded in the executing page. The "_source/skins/default" folder contains an example. The main skin file is named "editor.css". This file contains the CSS definitions for the editor interface. We may also have "dialog.css", containing dialog specific definitions. In the trunk/development version, editor.css contains a series of @import declarations. This makes the development code better organized. The release instead will have just one file, containing the minified version of all files. Class namesConsidering that all CSS definitions will be now loaded in the main page where the editor runs, we need ways to isolate them from other styles used in the page. Because of this, all classes used in the editor interface must be prefixed with "cke_". We must also consider that we may have two editor instances using different skins in the same page. For that, the entire editor interface is defined inside a container element which has the "cke_skin_<skinName>" class. Therefore, all CSS definitions for a skin must go under ".cke_skin_<skinName>". ResetTo be safe with the styles defined in the page, all skins must define a "CSS reset" set of styles, which clears those CSS properties that could interfere in the editor interface. For an example, see "skins/default/reset.css". Instance configurationThe <instance>.config.skin setting contains the name of the skin to be used for a specific editor instance. The skin name must match the folder name in the "skins" folder. The skin files are downloaded only once, and shared among all instances using that same skin. |
||||||||||||||||||||||||||||||||
#2460 | V3: Themes | Confirmed V3ProtoCore Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
The CKEditor prototype introduces the concept of "theme". The theme is the object responsible for building the editor interface structure. Each editor instance has its theme name in the <instance>.config.theme setting. It must match a folder name in the "themes" folder. A theme is defined in a file named "theme.js". The theme code must call the CKEDITOR.themes.add() function to register the "theme definition". The definition must define the "build" and "destroy" functions. See "_source/themes/default/theme.js" for an example. The "build" function injects the editor interface in the page. It defines the HTML structure to be used by the interface, and one or more "theme spaces" to be filled by other plugins. For example, the default theme defines a table with three rows. Each row contains a "theme space", named "top", "contents" and "bottom". The theme fires the "themeSpace" event in the editor instance, which can be listened by other plugins to fill the space with HTML. Finally, the theme inserts the interface HTML in the proper place in the page, according to the <instance>.elementMode property (replace or append to element). The theme code is also responsible to destroy the interface elements, with the "destroy" function. |
||||||||||||||||||||||||||||||||
#2461 | Context menu memory leak | IE6 | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
When consequtively opening and closing the context menu, the memory usage of IE6 increases. With the editor's table context menu, one can see the memory usage in the Windows Task Manager increase by every right click. With a larger CM it is seen even clearer. In my test the memory increased by 10MB+ for every click. |
||||||||||||||||||||||||||||||||
#2467 | Switching fullscreen in source mode fails after #2322 | Confirmed Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Reported in http://www.fckeditor.net/forums/viewtopic.php?f=6&t=10877 |
||||||||||||||||||||||||||||||||
#2469 | FCK.SetData() causes editor to become temporarily non-focusable in IE7. | Confirmed IE7 Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
This bug was originally reported by Mathias-S in our IRC channel. To reproduce the bug:
According to Mathias-S's original report, the bug can be reproduced in IE6 as well. But I wasn't able to do that in IE6. |
||||||||||||||||||||||||||||||||
#2471 | Ukrainian language file updates | HasPatch Review+ | Task | closed | Normal | ||||||||||||||||||||||||||||
Description |
All missing options have been translated. |
||||||||||||||||||||||||||||||||
#2472 | Splitting <th> produces a <td> instead of a second <th> | Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Insert the following table into the editor on the demo page <table width="200" cellspacing="1" cellpadding="1" border="1"> <thead> <tr> <th scope="col" colspan="2"> </th> </tr> </thead> <tbody> <tr> <td> </td> <td> </td> </tr> <tr> <td> </td> <td> </td> </tr> </tbody> </table> Splitting the header cell horizontally produces a <td> within the <thead> as opposed to <th> as shown below <table width="200" cellspacing="1" cellpadding="1" border="1"> <thead> <tr> <th scope="col"> </th> <td> </td> </tr> </thead> <tbody> <tr> <td> </td> <td> </td> </tr> <tr> <td> </td> <td> </td> </tr> </tbody> </table> |
||||||||||||||||||||||||||||||||
#2475 | V3: Globalization | Confirmed V3ProtoCore Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
The Globalization support has been introduced into the CKEditor prototype with [2365]. Just like FCKeditor, we try to guess the user language here, with a much simpler code though. The language file will be then loaded just one for all editor instances that share that same language. For RTL languages, the theme sets the "dir" attribute of the outer element that holds the editor to "rtl", and adds a class named "cke_rtl" to it. In this way, it is possible to properly skin the editor for RTL. Full language support has been added for plugins also. The "sourcearea" plugin contains an example of it. Just for this review, I've not added "en" support on the plugin, so you will note that the "Source" button will be localized to "Codice Sorgente", its Italian version for it (which is the default language of the plugin). Core plugins will have the language entries into the core language file, so the sourcearea language entries will be moved to the right place after this ticket review. The list of languages supported by the plugin is available in the plugin definition, so the end user is not required anymore to provide it. For the plugins, the language file is also cached and reused by other editor instances. It is possible to pack the core and the plugins language files with the packager, avoiding them to be downloaded from a different file. If the user language is not present in the packaged version, it will be downloaded from the lang folder, as usual. |
||||||||||||||||||||||||||||||||
#2477 | V3: Packager | Confirmed V3ProtoOther Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
I've worked a few days to come out with a new packager. I've started it as just a research thing, but the coded evolved into a real solution. For now, the code has been committed into the "_dev/packager/ckpackager" folder in the CKEditor prototype. The basic idea is stop doing string manipulations to the source code with miraculous regular expressions and use a real JavaScript parser. I've chosen Rhino for it, because it also made it possible to code all that stuff in our preferred language: JavaScript. Rhino is a full JavaScript parser, interpreter and compiler. I was more interested on the first part of it, the parser.
The results are pretty nice. Rhino gives us a "token tree". We then walk over this three and re-write the source, token by token. So, for example, if we find a VAR token, we just write "var" to the output. Under it, we have the NAME token, which contains the variable name, so we rename and write it to the source too. The results is "
Another interesting fact is that the parser gives us the "interpreted" token three. We don't have the exact same thing we had in the original code. A simple example; if we have " There are also several code enhancements that are done by this new packager. Things we would never be able to achieve with the previous packager. Check out the "test/test.js" file for a long list of examples. Btw, this implementation contains a basic automated test system, so we can be sure we are not breaking things on changes. In the "ckpackager/_dev" folder, you will find two batch files. Both of them are configured to act over the code available in the script.js file, present in that folder also. Just run dump.bat to have a visual presentation of the token three representation of that script. The compress.bat file will instead print the compressed result. There are several positive things with this packager. One of them is that all pending tickets for FCKpackager have been solved with it, and no ticket regressions have been found. Also, there are no special requirements when coding. No problems with missing semicolons, or even special ways to write things, like regular expressions and division signs. There are though a few negative things that need attention. The first is the performance. It is twice as slow as the previous packager. This is not a critical thing, and there is certainly room for enhancements here.
The other problem is that, this packager has been written based on coding patterns. I think I have handled all syntax situations in the current implementation, but, for example, I've written things like " For the configuration file, it is not using anymore an XML file. It uses instead a JavaScript object literal like syntax. For CKEditor, the "ckeditor.pack" file has been added to the root of the project. It exemplifies the package file syntax. Also, the _dev/packager/packagefilegen.html file has been updated to generate both the old and the new package file contents automatically. Just run _dev/packager/package_2.bat to execute the new packager over the CKEditor code. Regarding the deployment... Right now, the entire ckpackager folder is needed to run it. Java is required. This is another negative thing, as we just have a single file to be used with the previous packager to make it work. I haven't investigated it well, but I'm sure we are able to compile all that stuff in a single .jar file for the deployment, and possibly even generate an exe for it. But, this is something to understand yet. To conclude, here are the numbers I have, by running both packagers over the current CKEditor prototype (second run):
If we think this new packager is the way to go for us, I'll move it to its dedicated SVN three as a separated project and put an SVN external in the prototype three pointing to it. I'll wait the ticket review for it. |
||||||||||||||||||||||||||||||||
#2484 | noParse parameter in FCKDebug isn't used in the call to the debug window | Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Simple patch |
||||||||||||||||||||||||||||||||
#2486 | Vertically splitting cell with colspan > 1 breaks table layout | Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Tested below steps on demo page (v2.6.3) in FF and IE
Result: The cell is split vertically into 2 but only the first cell has colspan="2". The second cell is missing this colspan which breaks the table layout. |
||||||||||||||||||||||||||||||||
#2488 | Encode email "mailto:" links (Fix #2220) | Confirmed IE Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
This regards Fix #2220, adding the javascript based encryption of mailto links. This fix causes problems in Internet Explorer. When you click on an encoded (by FCK) mailto link on the frontend of a website, it causes IE6 and IE7 to do two things:
This problem exists in IE, but not in Firefox or Safari (what else is new). It's possible this has been resolved in 2.6.3 (we're running 2.6.3 beta) but there is no mention of it. Can someone kindly look into this? Thanks much for all your hard work! |
||||||||||||||||||||||||||||||||
#2492 | File Browser is not working with IE7 + Vista 64 Bits | Pending IE | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
in vista 64bits with ie 7.0 today I run vista update and fckeditor stop working correctly follow issue I have notes. when u try upload a file it works but the url does not show or attach to the image u select ie show script error on each image u click on |
||||||||||||||||||||||||||||||||
#2495 | Can't get properties of an image inside a div with some styles | Confirmed IE Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Some bugs have been marked as dups of #798, because the final situation is the same (and are due to the same internal IE problem), but the fact is that they are different issues. This problem started after fixing #1990, and it does include a call to set the focus in the editor FCKSelection.Save = function() { // Ensures the editor has the selection focus. (#1801) FCK.Focus() ; if that call is removed, then this problem goes away, but the context menu still fails, so this is not a dup of #798 as it could be possible to fix it. |
||||||||||||||||||||||||||||||||
#2496 | InsertHtml() ignores current selection in IE. Again. | IE Confirmed Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
It seems that this bug #2125 has come back again in Version 2.6.3 as I have having troubles with it. You can test this on the demo page with IE. It will insert the text at the start of the box instead of where the cursor is at when you open up the paste dialog. |
||||||||||||||||||||||||||||||||
#2503 | Dl aren't being formatted | Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
go to source mode and insert <dl> <dt>Ticket created </dt> <dd >The Globalization support has been introduced into the CKEditor prototype </dd> </dd> </dl> Now switch twice and the source won't be properly aligned. For reference, I just copied some text to test for #2407 (I copied from the timeline page that turns out to be a big <dl>) and when I tried to create a list I got an error: contentBlock.parentNode is null http://localhost/fckdev/editor/_source/commandclasses/fcklistcommands.js Line 322 But now it seems to work fine. Just in case anyone wants to try again. |
||||||||||||||||||||||||||||||||
#2508 | <ref> and <references /> tags break on edit | Confirmed Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
On editing a page with a <references /> tag at the end, the tag is replaced by wikicode: <references /> |
||||||||||||||||||||||||||||||||
#2512 | IE8 beta2, contents of dialogs don't fill the width of the container | Confirmed IE8 HasPatch | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Sometimes works, and sometimes fails. And sometimes suddenly changes from one situation to the other while the dialog is open. Check screenshot. |
||||||||||||||||||||||||||||||||
#2513 | IE8 beta2, insertion of tables is always done at the start of the document | Confirmed IE8 | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Sometimes I've seen also the img dialog fail, but the table always fails for me. |
||||||||||||||||||||||||||||||||
#2514 | the code should try to use Array.indexOf if it does exist | Confirmed Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
see http://developer.mozilla.org/En/Core_JavaScript_1.5_Reference:Objects:Array:indexOf and http://www.prototypejs.org/api/array/indexof The function in CKEDITOR.tools should be adjusted to call the native implementation if it is detected. |
||||||||||||||||||||||||||||||||
#2515 | Icelandic Language File 2.6.3 | HasPatch Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
Language file for Icelandic (new). 2.6.3 Compliant. The translator is a programmer and MA in Icelandic Linguistics, who has been using the file for his own website for two years. |
||||||||||||||||||||||||||||||||
#2516 | Remove the Array.AddItem method | Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
In fckjscoreextensions.js there's a Array.prototype.AddItem that it's just a custom implementation of the Array.push method, so we should remove it and replace its occurrences with .push. |
||||||||||||||||||||||||||||||||
#2525 | Chrome: error if FCKConfig.StartupShowBlocks = true | Confirmed Chrome Firefox Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Hello, If you execute FCKEditor on Google Chrome on the latest trunk (seem appear in the 2.6.3), I have an error if FCKConfig.StartupShowBlocks is set to true. Uncaught TypeError: Cannot read property 'nodeType' of null http://127.0.0.1/www.lib/fckeditor/edit ... wblocks.js (line 59) [...] if ( FCKBrowserInfo.IsIE ) { try { FCK.EditorDocument.selection.createRange().select() ; } catch ( e ) {} } else { var focus = FCK.EditorWindow.getSelection().focusNode ; if ( focus.nodeType != 1 ) Uncaught TypeError: Cannot read property 'nodeType' of null focus = focus.parentNode ; FCKDomTools.ScrollIntoView( focus, false ) ; } [...] To fix the problem I have just added "try catch" in the "else" branch. regards Frederic |
||||||||||||||||||||||||||||||||
#2531 | Scroll Into View Bug When Breaking Large Content (FF) | Confirmed Firefox Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
If you paste a large amount into the editor, where you end up with: <p> some large text <br /> paragraphs aren't there anymore </p> And you wish to put the paragraphs in to make it look like: <p> some large text </p> <p> paragraphs aren't there anymore </p> It will scroll the end of the second paragraph into view, which when the end is far enough away, will push the cursor off-screen, which can be confusing (why did I jump to the bottom?). If you continue to type, it'll start typing where the cursor is, not where the eye is, scrolling that back into view. The lines that cause the issue are fckenterkey.js lines 538/539: source:FCKeditor/trunk/editor/_source/classes/fckenterkey.js@2136#L538 I initially just commented this out, but then when you want to put in a new paragraph at the end, it will not scroll that into view. It seems to me that it should scroll when the paragraph is empty, but not otherwise, adding a FCKDomTools.CheckIsEmptyElement() will not work however, as we actually have: <p> <br _moz_dirty=""> <br type="moz"> </p> Some changes to the CheckIsEmptyElement() however will solve this (see patch). This does not completely solve the issue. When pressing enter with an "empty" paragraph being add, it will work fine. When pressing enter with a non-empty paragraph following, it works fine so long as it's not at the bottom of the view area, because then it doesn't scroll and should. This is a little better, but not complete. The best solution would be to move to the top of the paragraph, not the bottom. Is this possible?
|
||||||||||||||||||||||||||||||||
#2535 | translation in germany language | Confirmed Review+ | Task | closed | Normal | ||||||||||||||||||||||||||||
Description |
Hi Folkz, I have translated the language file to the end. Also the standard skin button was changed to german word style. If you would like to use it, it is posted in your forum: http://www.fckeditor.net/forums/viewtopic.php?f=5&t=11175 greetings Erde |
||||||||||||||||||||||||||||||||
#2543 | Namespaces excluded from using the FCKeditor | Confirmed Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
Old version (version by Mafs?) of the MW extension to integrate the FCKeditor included the ability to define certain namespaces that would be excluded from using the FCKeditor. This was handy for complex, densely tagged pages like in the Template and Help namespaces. The feature was called like this: $wgFCKexcludedNamespaces = array(8,1,-1); eg. "8" for disabling the editor within the MediaWiki namespace. We use Semantic MW and Semantic Forms, so I need to turn off FCKeditor to all users in the Forms, Property, and Concept namespaces in addition to Special, Template, Image, and Help. Allowing users to to control whether or not to use the FCKeditor in their preferences is not a good option; does not address custom namespaces. |
||||||||||||||||||||||||||||||||
#2554 | Select All using Ctrl-A does not work in modal dialog | IE | Bug | confirmed | Normal | ||||||||||||||||||||||||||||
Description |
The 'Select All' toolbar button can be used to select all content in the editor window. This works when the editor is loaded in a normal window or in a modal dialog window. However, although the Ctrl-A keyboard shortcut works in a normal window, it does nothing when the editor is running in a modal dialog box. Versions: 2.6.2 OS: Windows XP Browser: IE6 Steps to reproduce: Implement an instance of FCKEditor in a page, and load the page in a modal dialog box (Window.showModalDialog() in IE). Enter some text in the editor. Use the 'Select All' toolbar button, and note that all content is correctly selected. Deselect the content. Now press Ctrl-A. Note that content is NOT selected. Load the same page in a normal window. Repeat the above steps. Note that Ctrl-A does now select all of the content. |
||||||||||||||||||||||||||||||||
#2560 | Background color applied to Text in IE when I select all | IE | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
If I have a background color set in my css, then I go Select All, and then type and then save. The background color gets applied to all my text with <font style="background-color:(a color);">my text</font>. This only happens in IE, firefox it does not. I have made a work around for this, attached is the plugin I wrote the does the select all pretty well. |
||||||||||||||||||||||||||||||||
#2567 | Slovak Translation Update | Confirmed Review+ | Task | closed | Normal | ||||||||||||||||||||||||||||
Description |
Update to Slovak translation (localization) file - updated missing translations and mistakes correction. |
||||||||||||||||||||||||||||||||
#2573 | ASP: In the connector, IsAllowedType must be case sensitive | Confirmed Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
The current implementation of IsAllowedType is case insensitive, but all "per type" configuration options are case sensitive. So, the connector will accept types with just case differences, but will break later, when trying to retrieve settings for them. We should be always case sensitive for the type instead. |
||||||||||||||||||||||||||||||||
#2577 | when SourcePopup is true, closing source results in permission denied | IE | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
When you set your FCKConfig.SourcePopup = true in the fckconfig.js, upon pressing OK to close the source view popup page, it gives you a javascript error saying: Line: 65 Char: 2206 Error: Permission denied Code: 0 URL: [mydomain]/[fckeditor_home]/editor/fckInstanceName=[myfield]&Toolbar=Basic How to reproduce this bug:
This only happens on IE 7.0.6, it works fine in Mozilla Firefox. Remember, to get this bug to happen, you MUST set the source popup to true. If you set it to false, it works fine. |
||||||||||||||||||||||||||||||||
#2587 | IE7 > (#2115) Permission denied to get property window.OnUploadCompleted | Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
I get the same problem on IE7 as described in ticket #2155. FCKeditor.prototype.Version = '2.6.3' ; FCKeditor.prototype.VersionBuild = '19836' ; All works within Firefox. Checked patch from #2115 and its applied to this version. |
||||||||||||||||||||||||||||||||
#2597 | Safari: drop from outside the editor is disabled | Confirmed Safari Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Since the introduction of [589] the external drop of elements in FCKeditor is disabled in Safari. That's meant to respect the ForcePasteAsPlainText setting, but every drop is always disabled in this code: var cancelHandler = function( evt ){ evt.returnValue = false ; } this.EditorDocument.addEventListener( 'dragenter', cancelHandler, true ) ; this.EditorDocument.addEventListener( 'dragover', cancelHandler, true ) ; this.EditorDocument.addEventListener( 'drop', this._ExecDrop, true ) ; |
||||||||||||||||||||||||||||||||
#2603 | Set EMailProtection to none by default. | Confirmed Review+ | New Feature | closed | Normal | ||||||||||||||||||||||||||||
Description |
Ok, I have noticed that this is a problem too late, but I guess we can still turn it off. Reasons why I think it should be disabled:
I think we have made a mistake by enabling it by default, but it may bee too late to change this. Anyway I'm posting this here for consideration. |
||||||||||||||||||||||||||||||||
#2604 | Response.CodePage | Confirmed Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
The addition of the Response.CodePage variable in the basexml.asp file is causing Browser failures when browsing for files. The OS is Windows Server 2000 with SP4 using IIS. Commenting out this line does remove the error, but the repercussion is that larger data imported into the editor will be truncated at 64.5k characters. |
||||||||||||||||||||||||||||||||
#2611 | extra slash with quickupload in asp | Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Using the quickupload shows the uploaded path with an extra slash in the asp connector. The patch also removes an extra byte at the end of the upload class, just a minor detail. |
||||||||||||||||||||||||||||||||
#2612 | Chrome: "Paste as a plain text" option not working | Confirmed Chrome Safari Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Windows XP sp3 FCKeditor 2.6.3 Drupal 6.6 Drupal module: fckeditor-6.x-1.3-rc3.tar Google Chrome fckconfig.js: FCKConfig.ForcePasteAsPlainText = true ; Using Google Chrome, "Paste as a plain text" popup not appear. Always appear "Paste" popup, regardless of fckconfig.js configuration. |
||||||||||||||||||||||||||||||||
#2616 | IE sometimes still insert at the beginning | IE Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Despite the previous fixes for the 2.6.4 milestone, in the current SVN there are still some situations where IE can insert the new content at the beggining. One example is using the easyupload file dialog: http://martinezdelizarrondo.com/easyupload For the moment this is the best option that I've found:
|
||||||||||||||||||||||||||||||||
#2634 | Bug with FCKXhtml.SpecialBlocks | Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
When SpecialBlocks have child nodes, the call to AddItem fails, as it was removed recently I believe. This can be replicated with the manual fckxhtml test. I'll attach a patch I believe resolves this momentarily. |
||||||||||||||||||||||||||||||||
#2649 | IE: Error on Find dialog with "match whole word" | Confirmed IE Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Steps to Reproduce
A JavaScript error is thrown. It looks like an IE only issue. Works well with Firefox. |
||||||||||||||||||||||||||||||||
#2650 | Danish language file updates | Confirmed Review+ | Bug | closed | Normal | ||||||||||||||||||||||||||||
Description |
Danish language file updates |