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.

  1. General editing
  2. External editor
  3. DOM Inspector
  4. Lists
  5. Tables
  6. CSS Editor
  7. Publishing
  8. Miscellaneous

Feature requests

  1. General editing

Bugs and enhancements detailed

Key to column headings

Local record Number
The id in the Sourceforge KompoZer Tracker bugs list
The category as Bug or 'FR' (Feature Request - Desired enhancement)
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.
The version at which the problem was noted as fixed. The row will also be marked by striking out.
Description of what the bug or enhancement is. Will include link to a test case file if appropriate.

Table with details

Cat First Cleared Description
2601796 Bug
0.8a4 0.8b2
The option 'Return in paragraph always creates new paragraph' doesn't ever do this. It inserts a <br> element.
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


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
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
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

? 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.
2889030 Bug

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.
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.
2822759 Bug

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.
2877221 Bug
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

When attempting to Publish to the subdirectory specified by the prefix the required directory is not created so publishing fails.
2790630 Bug 0.8a3
Empty divs disappear even if allocated an id. Still present in 0.8b2
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:
  • Open two files.
  • In one select something
  • Switch to Split view
  • Switch back to design view. All drop down boxes etc will be greyed out and inoperable.
  • Switch to the other file. The box on format toolbar 1 is greyed out but that on Format toolbar 2 is clear.
  • Switch back to the first file. The box on format toolbar 1 is greyed out but that on Format toolbar 2 is clear as for the other file. The Font selector drop down now works but the other is inactive.
  • Any new file created copies the boxes in the same states.
To recover you must close and reopen KompoZer. Still present in 0.8b3.
2901043 Bug 0.8b1
Sometimes in Design view, after selecting a text block e.g. <p> 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.
To recover you must close and reopen KompoZer.
Steps to reproduce:
  1. Open KompoZer.
  2. Open one file
  3. Open a second file
  4. Try to change an element in the first file. It cannot be changed
  5. Try to change an element in the second file. It can be changed.
Still present in 0.8b3.
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.
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:
  1. Ensure that the HTML file has more than one stylesheet and that the one involved is not first on the list
  2. Expand the stylesheet to be changed
  3. Make a change to a rule
  4. Make the required change in the 'Media List' box
  5. Move the stylesheet up in the priority list
  6. Make a change to the HTML
  7. Save the file
Steps3 and 7 ensure that both HTML and CSS file will be saved. After that go back and restore any made changes at steps 3 and 5 that you would have preferred not to make.
The problem was inherited from Nvu so is not high priority to fix.
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:
  1. Create file
  2. Link to stylesheet which includes comments. e.g. one created using KompoZer 0.7
  3. Make any change to a rule, Click OK
  4. Change the order of the stylesheet up or down a level, Click OK
  5. Change a rule again, Click OK
  6. Change the HTML and Resave the page.
Every rule will now be prepended by a universal selector followed by a vertical bar. e.g.
*|body {
font-family: sans-serif;
2899340 Bug

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 <br> following H1. BR does not delete
b - Select body, delete <H1 element>. Heading does not delete.
c - Select <p> element. Insert within it </p><p>. The paragraph splits into two
d - Select <div> element. Delete the </p><p> tags recently added. The paragraph remains split into two. In this case I occasionally have managed to concatenate the two.
e - Select <div> element. Delete the one of the <p> elements. The paragraph is not deleted.
Still present in 0.8b2.

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.