KompoZer 0.8b3 pre-release -
Selected bugs and enhancements
A personal experience
This page is essentially a personal list of bugs – those that I have encountered so far when working with KompoZer 0.8 when using Windows® XP Home. Unless I have found them on KompoZer Bug Tracker[ref1] at Sourceforge I will report them there but I do this only when I have established that the effect is reproducible, I can describe it adequately and I don't know that the developer is already aware of the issue.
In addition to bugs I have included some potential entries for the Feature Requests Tracker[ref2], again a personal selection but I hope closely related to the current User Interface.
Potential bugs
I have grouped related bugs together.
- General editing
- External editor
- DOM Inspector
- Slow response to id - R6
- Lists
- Tables
- CSS Editor
- Publishing
- Miscellaneous
Feature requests
- General editing
Bugs and enhancements detailed
Key to column headings
- No
- Local record Number
- Id
- The id in the Sourceforge KompoZer Tracker bugs list
- Cat
- The category as Bug or 'FR' (Feature Request - Desired enhancement)
- First
- I started tracking these bugs more carefully from version 0.8b1. The column indicates the first version on which I noted the bug, any predating 0.8b1 are approximate.
- Cleared
- The version at which the problem was noted as fixed. The row will also be marked by striking out.
- Description
- Description of what the bug or enhancement is. Will include link to a test case file if appropriate.
Table with details
No |
Id |
Cat | First | Cleared | Description |
---|---|---|---|---|---|
1 |
2601796 | Bug |
0.8a4 | 0.8b2 |
The option 'Return in paragraph always creates new paragraph' doesn't ever do this. It inserts a element. |
2 |
2892098 | Bug | 0.8a4 | 0.8b2 |
Return at end of paragraph behaves as return in paragraph. To form a new paragraph you need to press Enter twice. Probably related to No 2601796 |
3 |
FR |
Nvu |
Pressing Return at the end of a heading returns you to body level. It would be preferable to create a new paragraph. Still present in 0.8b3 | ||
4 |
2889027 | Bug | Nvu | The editing position flashing cursor can sometimes disappear. This occurs if relatively positioned divs follow each other, the position needed is not in the first div and you have to scroll to reach it. Sometimes the cursor appears to be cropped rather than invisible. Test case. Still present in 0.8b3 |
|
5 |
2889033 | Bug | 0.8b1 | On opening the icon on Format Toolbar 1 for the HTML editor is greyed out. Switching to Split or Source view revives it. Bug not present with 0.8a4. Still present in 0.8b3 | |
6 |
? | 0.8a4 | When updating (i.e. not originally creating) e.g. an id by double clicking the marker in the DOM inspector the change occurs but is not reflected immediately in the inspector. | ||
7 |
2889030 | Bug |
Nvu |
When creating definition lists the first child of the dl is dd. It should be dt. This is not as bug. The User Guide changed 29th Nov 2009. |
|
8 |
2792618 | Bug | 0.8a4 | When list elements have display:none; br elements are added before the li closing tags. Additional br elements in the same places may also added each time a page is edited is editing is in source or split view Test case. Still present in 0.8b2. |
|
9 |
2822759 | Bug |
Nvu |
Tables are created with inline styles e.g. text-align: left; This has the effect of rendering rules in style sheets impotent. Still present in 0.8b3. | |
10 |
2877221 | Bug |
0.8a4 | Table cells are created with inline styles e.g.vertical-align: top; This has the effect of rendering rules in style sheets impotent. Still present in 0.8b3 | |
11 |
Bug |
0.8b1 | When attempting to Publish to the subdirectory specified by the prefix the required directory is not created so publishing fails. |
||
12 |
2790630 | Bug | 0.8a3 | Empty divs disappear even if allocated an id. Still present in 0.8b2 | |
13 |
2892112 | Bug | 0.8b1 |
The drop down boxes on Format toolbars 1 and 2 (along with some buttons on the Composition Toolbar Anchor, Link, Image, Table, Form and sometimes Save.) become greyed out and their functions don't work. Steps to reproduce:
|
|
14 |
2901043 | Bug | 0.8b1 |
Sometimes in Design view, after selecting a text block e.g. element, it is impossible to change the element, to e.g. a heading, by using the element drop down box on Format Toolbar 1. The box is not greyed out. There are no other symptoms.
|
|
15 |
2892496 | Bug | 0.8a3 | ? |
When KompoZer is open but not in the foreground if you track the mouse cursor from the taskbar or any place on the desktop attempting to access another application, which might be in the foreground, and if the track crosses parts of the KompoZer window, KompoZer jumps to the foreground. Sometimes this can make other applications almost inaccessible. The parts of the KompoZer window involved seem to be associated with the status bar. This seems to have been fixed in 0.8b3 but not marked as such in bug tracker so still to be verified. |
16 |
2893505 | Bug | Nvu |
It is very difficult and non-intuitive to change the media type for a CSS file. The only reliable method seems to be:
The problem was inherited from Nvu so is not high priority to fix. |
|
17 |
2893507 | Bug | 0.8b1 | 0.8b2 |
Sometimes CSS3 namespace components are prepened to all selectors in a stylesheet. This bloats code and possibly (???) introduces compatability issues. For instance this occurs in the following case:
*|body { font-family: sans-serif; } |
18 |
2899340 | Bug |
0.8b1 |
Many editing functions which are easy in source view appear impossible or near impossible in Split view. The Test case gives examples. In the test case the paragraph "This is a short paragraph which is to be split into two" can demonstrate several problems. The same method is used in each case: 1 - Select element using DOM inspector or status bar. 2 - Go to Split view 3 - Edit as required. 4 - Return to Design view 5 - Return to split view to check if edit has stuck. Some examples a - Select body, delete following H1. BR does not delete b - Select body, delete . Heading does not delete. |
|
19 |
2964440 |
Bug |
Nvu |
When you set up a CSS rule using the background-image property, unlike when you insert an image you are given no option as to whether the image path is absolute or relative. The path is always set up as relative. This is probably the correct approach and has caused no problems in practice. When you set up a background image using an inline style, with the style attribute, the path is set up as absolute pointing to the author's drive. This is obviously unsatisfactory after the file is uploaded but the problem may not be noticed until then. A simple workaround is to open the inline style editor a second time when it will be discovered that the path is now relative. This problem dates from Nvu. This workaround should not be required. |