Build 21 (2007-12-01): Fortunately, most of the bugs fixed were trivial and easy to fix. The only major change is the addition of @TabList and @WindowList for the menus.

Current Bugs

Tab bugs/improvements

I have observed several times that the current tab is duplicated (reopened in a new tab). I'm not sure how to reproduce it. It just happened again when I closed a window of a different application on top of the browser window. (kko)

Interesting. Did you set kmeleon to duplicate the current tab when opening a new one? (dorian)

No. (kko)

I could reproduce it now:

Right-click any tab button (to open the tab button popup menu).

Press Esc or left-click into the document (to make the menu disappear).

Move the mouse cursor over the tab bar.Result: The previously right-clicked tab is duplicated (reopened in a new tab).This is related to the other tab button popup issues mentioned below (menu pops up again, link symbol/duplicate) and may already be fixed in build 24. (kko)

When loading a page in background, the loading icon stays visible behind the default/website icon when the page finished loading (until the tab is hovered or a new one is opened).

Never happened to me. Could be system specific, I may force a refresh if needed (dorian)

Depends on what icon you're using. When the loading icon is completely covered by the opaque parts of the default or website icon, you can't notice it of course. (kko)

kmeleon.tabs.fixedBar

seems to be ignored when kmeleon.tabs.bottomBar is true. This may not be desired when the Tab Bar is auto-hiding.

FIXED build 24

false

Toolbars locked => tab bar unlocked (after a restart)

browser.tabs.autoHide true and menu bar hidden => the first tab button is always elevated (hovered) when not pressed

In the meantime I have to say 'most often' instead of 'always'. I'm experiencing instabilities in this configuration (menu bar hidden). Sometimes the browser crashes or hangs at startup. Sometimes toolbars.cfg button bitmaps are not displayed (not always the same toolbar, but always all buttons of that toolbar were affected). May be related to the loader. I'm going to observe this further... (kko)

true

Toolbars unlocked => tab bar locked

The Tab/Window Buttons seem to be assumed 16x16 pixels in size, bigger buttons are cut off.

It's not related to autoHide. At first, the Find Bar is displayed below the bottom Tab Bar. But when you open a new tab, the two bars exchange their positions - the Find Bar jumps on top of the Tab Bar. I think that the Find Bar should always be on top of the bottom Tab Bar - that makes more sense to me than the other way round. (kko)

Right-click a tab button (to call the tab button menu), then right-click onto a free space in the tab bar and keep the button pressed for an instant => the link symbol appears and the previously clicked tab is duplicated when the button is released (kko)

FIXED build 24 I think

There is no right click context menu for items in the chevron drop down list (">>") and you can't drag'n drop an entry from there to some other place in the tab bar.

With a certain number of open tabs (grow them one by one) the last tab is displayed twice 1) at the end of the tab bar and 2) as the first (and only) item in the chevron drop down list (">>") on the right.

FIXED for 1.5a2 (build 23)

Tabs should be closed upon releasing the mouse button, not when starting the second click from the doubleclick (so you can keep the button pressed and move the mouse away to *not* close the tab) (ra, 2007-11-20).

The undo close make this VLP (Very Low Priority)

Isn't that just a matter of switching from mouseDown- to mouseUp-event? It's not only about undo close, but also usability - AFAIK all other browsers react on mouse button release.

no, I'm using the doubleclick event.

I still have problems getting used to it, but if no one else complains...

Fixed for middle click and right click (build 23)

Regressions from 1.1.x

Build 23: A click on the loader icon in the tray does no longer open a new browser window when there is already a window open. (kko)

Same when double-clicking k-meleon.exe.

FIXED build 24

Build 22: The new profile component seems to have a problem with the -P command line switch (haven't tried -profilesDir). When I have an instance running and want to start a new one using "-new -P", I always get a warning that the profile was in use. But the profile I've specified in the command line isn't in use. (kko)

FIXED for 1.5a2 (build 23)

Confirmed fixed but want to make further tests, so don't move this bug. (kko)

There are disabled menu entries for tabbed browsing in the right click context menu on links (and on File and View menus as well). Why are they there at all in non-tabs mode? Please remove them if tabs are disabled - there are users that don't want to be bothered with tabbing stuff unfortunately...

We're still unsure on how we will handle that, maybe splitting the menu conf file.

What about not displaying disabled menu entries or exposing tabs as conditionals ("if tabs" the same way plugins can be checked, like "if macros")? (ra, 2007-11-20)

Locked menus are misaligned (buttons move to the left and leave space on the right, looks ugly compared to versions < 1.5, especially if you put several bars on the same row next to each other)

Not sure why but you have to resize the browser after locking/unlocking for them to realign correctly.

Dorian: That doesn't fix it (use a different skin than Phoenity). I think, the width of the toolbars has to be reduced when locking the toolbars (the grippy is then removed, but the space required for the grippy is not - at least not always). (kko)

There is another problem: button graphics overlapping the vertical line after locking (ra, 2007-11-20)

FIXED for 1.5a2

Still an open issue with build 21. (ra)

There is no difference in behavior compared to IE

There is one: IE(7, don't have IE6 anymore) doesn't move the toolbars if you lock them. Please compare the current situation with K-M 1.1 and prior and revert to the way it was.

It does. Check the menu bar and the links toolbar. The rest are not real toolbars in IE7.

Okay, the menu bar moves. But the Links toolbar doesn't move at all, just the grippy is removed. Great, but there seems to be some logic behind it: Button(-bar)s don't move when they are locked, menus do. %-)

Can't say that I had noticed any difference in build 21. Can't say either that I liked the behavior of pre-1.5 versions better. The question is how do we expect "Lock Toolbars" working? Maybe we should discuss that first, before chasing Dorian back and forth? (kko)

Have a look at the upper left part of the screenshots here: km11 vs. km15 The primary part that I don't like there is the space on the right of the button when a new bar follows. Please also note the the close button on the far right side automatically moves somewhat to the left when the window is maximized, although it can't be placed further to the right when the toolbars are unlocked. -- I propose a homogeneous layout with bars that keep their positions when you choose to lock the bars. There are some buttons a user might want to keep on the left and some on the right side, so it's difficult to decide where to move the bars if you don't add logic to move to the left if the bars start <50% width of the window and to the right if they are placed >=50%of the window...

The bars doesn't move. The buttons just reclaim the space used by the gripper. Preventing this is not something I can really do. If I do what you say, one of the toolbar will end up with all the extra space. But how can I know what bar it should be? Previous behavior was a bug, and it wasn't really consistent since new behavior could be triggered after some manipulation. (dorian)

Try the following (build 22). Unlock your toolbars, open about:config, enter "band" into the filter bar and reset all user-set kmeleon.toolband.<...>.size prefs. Close km and open <kmDir>\defaults\pref\skin.js. Comment out all kmeleon.toolband.<...>.size prefs exceptkmeleon.toolband.Menu.size and kmeleon.toolband.URL Bar.size.Set those to 1400 (or even higher). Now restart km and lock/unlock your toolbars. As long as you don't move/resize any toolbars, the locking/unlocking is then working how I would expect it. That is to say, the button toolbars (those defined in toolbars.cfg) are just as wide as necessary (non-greedy). The others are always as wide as possible (greedy). (kko)(Also try it with all ...size prefs in skin.js commented out. There is a noticeable difference between the locked and the unlocked URL Bar.)

I confirm, but since kmeleon doens't do any drawing you can't blame it for this bug. As a workaround you can disable the background bitmap.

What can be blamed then? ;-) I haven't noticed this problem in any other app so far (and there are several skinned ones around) and I think it didn't happen with previous versions. (ra, 2008-02-28)

KMeleon only use the toolbar background used by IE. Maybe there are case where it need to be refreshed, but that's just weird.

The browser doesn't remember its previous window size (maximized in my case, tabs are off) on startup and when using "undo last closed window". In the last case the opened window has the status maximized while it covers only a third of the screen, so you first have to restore it (to the exact same size) in order to correctly maximize it.

OPEN in build 21 (close browser maximized and start it again => not maximized)..

Look fine for me. Could be OS related?

I observed the same behavior under 2k and XP. (kko)Make sure you don't start with a session!

FIXED build 24

Window state "maximized" is not correctly restored for saved sessions when the current window is maximized. The middle window button in the title bar indicates "maximized", but the window itself isn't. Maybe this is already resolved when sessions are opened in addition to the current window...

FIXED for 1.5a2 (build 21)

Is "Resume" really working with downloads? I had a download that stalled, so I clicked on "Pause", waited a second and clicked "Resume" - but there was no reaction at all, neither on the download nor the connection visible. (Closing the browser and restarting it and starting the download again led to a successful download.)

There are 2 methods called pause and resume. I'm just using them ;+)) This work like firefox pause/resume.

Resuming paused downloads works for me. (kko)When a download is stalling, it's because the server is too busy or isn't responding anymore at all. Obviously, you cannot resume the download when the server isn't responding...

Well, you can resume if the server was just down for a second, the download stalled for some other reason (but the server is reachable in general) or your connection broke away. But in all these cases you can't resume the download with K-M. That makes this feature kind of useless, because you have to start the download again manually (and it will process fine then) cancelling the initial download ... (ra, 2007-11-20)

Dorian: Why is the Pause/Resume feature only offered when you choose to "open" a download?

What do you mean? Just saved something and pause/resume was working.

:p Forget about it. Found something else:

Start a download, pause it, then cancel it. Try to start the download anew.AFAICT, the connection is kept alive while the download is paused. Cancelling the paused download, doesn't terminate the connection however. When you try to restart the download, km indicates being busy, but nothing happens. (kko)

FIXED for 1.5a2 (build 21)

Should it be fixed for a stalled download or connection loss while downloading, too?

ra, from my point of view, you are mixing up two different things (kko):

You are talking about HTTP Resume, as it is known from download managers. Km (i.e. Gecko) supports that as well. When a download is interrupted, all you can do is closing the download dialog and starting the download anew. Km can read the downloaded part of the file out of its cache and can automatically continue the download where it was interrupted, provided the server allows that.

The purpose of this new pause/resume button is just pausing a download temporarily in order to gain bandwidth for something else. While paused, the connection to the server is kept alive. Once this connection is interrupted, you cannot resume the download - not with the pause/resume button. The purpose of this button is not forcing HTTP Resume!

The button should be able to handle both scenarios. Normal users won't know about it and blame K-M for not resuming their downloads (like a download manager would do), although they hit the button to do so after (e.g.) a connection loss. -- Please note that if I had to decide which feature to add, I'd personally go for HTTP Resume (or re-downloading the whole thing if HTTP Resume is not supported) and not pause/resume. Dorian decides, but please consider the fact that having a Resume-button that does absolutely nothing in all the scenarios described would certainly be a doubtful feature, because "true" resume (HTTP resume/redownloading) would be lacking.

The usefulness of this new feature is out of question to me. You simply misunderstood its purpose. In order to avoid such misunderstandings, I suggest to simply rename the button from Resume to Continue. Then this feature is less likely to be mixed up with HTTP Resume. (kko)

Old bugs

Difficult to reproduce bugs

Core/Gecko: K-M's sometimes stalling. It's just doing nothing for several seconds (20-30), no progress while loading pages in any window visible (and no data transfer either!), and then it progresses fine. It might happen only if one of the windows is a page with many many small thumbnails, that K-M is loading quite slowly, but it most likely seems to happen when a page is not responding. (One not responding site is hanging the whole browser.)

I've observed this too with km 1.1a3/b1 accessing our forum. When the SF/Chongqed logo hosting servers aren't responding, the browser seems to be locked, the GUI is not responding. I could reproduce the exact same behavior in SeaMonkey 1.1.1.Confirmed - SeaMonkey/Gecko bug (kko)

Will that still be a problem with KM1.5?

Look like it. KM still hang some time, and I'm unable to find where.

Mmm my case was different I guess. For me it happens after browsing a site with java. This can be incredibly annoying (freeze 2-3 seconds after each page load). (dorian)

There seems to be a similar problem with many tabs open: If you click on a link and/or open a new tab the browser is unresponsive until the site actually begins to load(mmh, make that render?), with K-M pausing for 2-3 seconds inbetween.

Improvement wishes of currently new 1.5 features

Better command registration, with a way to get the list of available command.

Add more gecko event (to improve macro functionnality)

Skin support png & zip

More gestures for gesture plugin, like first left then right and first up then down gestures (Hao Jiang, 2008-01-21)

Sessions plugin

Delete kmeleon.plugins.sessions2.<session>.count togther with the session.

Improvement wishes of older features

Please remember a proxy's username and password. Currently users have to re-enter the username and password every time the browser is started. (ra, 2007-11-20)

How does kmeleon ask for username & password? No checkbox to remember password?

The usual prompt appears, username & pwd. can be saved, but they are not remembered (might be related to the fact that I'm sometimes prompted to enter the data while the browser is still open, so I'm not 100% sure what's to blame). BTW: The site name is only displayed as "", but the url is correct. -- I'd favor a pref for proxy's credentials like other browsers handle it.

I'm afraid kmeleon can't do much for this, probably the password manager is not doing its work (or you have several password stored for the same domain, or maybe because it's empty). Kmeleon just display what gecko ask for. Any way for me to test it? (just to be sure)

Is there no way to store the data for the proxy with Gecko aside from the usual password manager? I'm afraid I don't know a proxy to test it, as the one I'm having the problem with is a corporate proxy that's not accessible from the Internet.

I don't think so, I wouldn't even know for what domain I should save it. :-\

Too bad. ;-( It's a bit annoying that you always have to either hit return (username&password remembered) or enter username&password every time the browser is started again. Firefox remembers the credentials somehow and doesn't ask for them all the time (only when the proxy re-asks for them I think).

Invalid bugs (won't fix / no fix needed / ...)

Tab bugs/improvements

kmeleon.tabs.useLoadingTitle seems to be ignored. The loading title is always displayed.

Only displayed until kmeleon get the page title (dorian)

Sounds logic, indeed. So, no bug. (kko)

Regressions from 1.1.x

Other bugs

If you enter s.th. in a text box while a cookie prompt is open you'll write right to left... (just noticed that, dunno about 1.1)

A know bug with Gecko 1.8 with modal dialog in general, there is a know workaroud for it but I've never implemented it because nobody ever complained about it.

Old bugs

Favicon transparency issue with http://xs209.xs.to/xs209/06472/favicon.png e.g. (black background instead of transparent), because "they use a 2bpp transparency bitmap, which is not supported by window. Which mean I have to convert it to a 4bpp image.".

Not a Bug: browser.chrome.favicons is false by default (I so hate all those missing favicon.ico in server log caused by firefox).

Difficult to reproduce bugs

Verified fixed bugs (won't be checked any further)

Tab bugs/improvements

Bookmark groups (nick-names) should be opened in background *tabs* if tabs are *on* (not background windows like in 1.5a1/2) and in background windows if tabs are off -- or there should be a setting... (ra, 2007-11-20)

That's the purpose of kmeleon.general.opengroup

Okay, so kko, how about toggling that one when tabs are enabled/disabled?

FIXED for 1.5a2

Please highlight the current tab item in the drop down list that appears on the right (">>") if you have too many tabs open, just like the current tab in the the tab bar.

FIXED for 1.5a2 (build 21)

Confirmed as fixed in build 21 with a checkmark. (ra)

Regressions from 1.1.x

Missing substitute for kmeleon.plugins.layers.rebarBottom (kko)

FIXED for 1.5a2 (build 23)

Build 22: I'm missing the cross on the close button of the find bar (kko)

FIXED for 1.5a2 (build 23)

Using type ahead find pressing F3 doesn't take you to the next result anymore, but opens the Search-prompt (instead).

'Search-prompt' meaning 'Find Bar' (kko)

FIXED for 1.5a2 (build 22)

Missing substitute for layers() in menus (list of current tabs) (kko)

FIXED for 1.5a2 (build 21 add @TabList)

Macros plugin: setmenu(...,where) with where=0 seems to work like where=-1 (the item is added at the end of the menu, not at the beginning) (kko)

is it a setmenu() only issue? (ie settings.cfg is not affected?) (dorian)

no, position index has generally no effect in menus.cfg (items are always added at the end of the menu);labels and commands are working correctly in both setmenu() and menus.cfg (kko)

FIXED for 1.5a2 when 0 is used for position in setmenu(). The rest didn't change since 1.1

Text in cookie prompt partly broken: "The site ... wants to set a cookie" - instead of the site's name there are only "boxes" visible (Unicode character problem?). The details shown below the text work.

FIXED for 1.5a2

Confirmed as fixed in build 21. (ra)

Old bugs

Local files with umlauts or accents in the path name fail to open in external applications (external source code editor and apps called through macros). (kko)Such characters are double-escaped (%??%??) in km's URL. Most Windows apps fail to interprete this correctly (e.g. IE and Notepad).

Macros:The exec() statement suffers from the same problem. I guess, we need an urldecode() function?

FIXED for 1.5a2 (build 22)

Keyword Autosearch doesn't work when Typed URLs are set to open in a new tab (kmeleon.general.openurl = ID_OPEN_LINK_IN_NEW_TAB) or background tab (kmeleon.general.openurl = ID_OPEN_LINK_IN_BACKGROUNDTAB). Same in 1.1 with layers. (kko)

FIXED for 1.5a2 (build 21)

Difficult to reproduce bugs

Probably Macros Plugin: The save as directory is not always remembered. With numerous windows open (windows only mode), changing the directory in one window doesn't always change it for the others. It doesn't matter whether page load is still in progress or finished. Works correct when there are no kmms loaded (macros plugin disabled or main.kmm absent). Not caused by kmm code. Could not reproduce it yet, can't say anything about layers. Report (kko)

Haven't had this problem with 1.5a2 yet. Was there some change that might related to it? (ra)

Too much to tell :)

Confirmed as fixed (ra)

The first bookmark or favorite opened after startup is sometimes opened in a new background window, although the browser is configured to open it in the current window. It works like it is supposed to for subsequent items.

Can't reproduce currently

Can't reproduce either (kko)

Mmh, can you try again, the bug's there. And possibly related: With tabs on only the first bookmark of a bookmarks group is opened when you first try it (enter the nick in the url bar). When you open the group again (enter the nick again) the other bookmarks are opened, too; but in background windows - I suppose they should be opened in background tabs when tabs are on. (ra, 2007-11-20)

More exact: Disable tabs, restart the browser (just to make sure). Open a page and open several links from that page in new background windows. Now open a bookmark. => The bookmark will load in the last window opened in the background overwriting the page that was loading there, instead of the current page. If you open the bookmark again in a different window it will load in this window like it is supposed to do.

FIXED for 1.5a2 (build 21)

Confirmed as fixed in build 21. (ra)

Improvement wishes of older features

A chevron drop down list for the menu bar would be nice if the menu is partly hidden by button bars.