I started this thread because I thought the 1.3b thread was getting ridiculously long. Anyway, since the new Mozi-Meloen builds were taking double the time to startup compared to the latest official release I decided to get rid of the extra baggage that was in components and chrome to see if it made any difference and it did. The 1.2.1 build now starts as fast as the latest official build and runs without a problem(besides the persistent user32.dll errors). Only one problem, I now have no scroll bar. What do I need to put back in? The following is what I removed:

In Program Files/K-Meleon M1.2.1

fort32.dll
ISimpleDOMDocumentMarshal.dll
ISimpleDOMNodeMarshal.dll
mfcEmbedComponents.dll
nsldap32v50.dll
nsldappr32v50.dll
swft32.dll
xpistub.dll

In chrome

Folders:

classic
comm
content-packs
en-US
en-win
icons
inspector
pipnss
pipkki
toolkit
Us
venkman

Files:

chromelist.txt
classic.jar
comm.jar
content-packs.jar
en-us.jar
en-win.jar
inspector.jar
toolkit.jar
US.jar
venkman.jar

In components

appcomps.dll
autoconfig.dll
imgicon.dll
imgmng.dll
inspector.dll
intlcmpt.dll
mork.dll
mozfind.dll
mozldap.dll
nsprefm.dll
oji.dll
regviewr.dll
universalchardet.dll
wlltvwrs.dll
xpctools.dll
xpinstal.dll

Heheh, your about: no longer works either.

You need in the \chrome dir:

subdirectories - \icons\, \classic\, \en-US\, and \US\
files - classic.jar, en-US.jar, US.jar, chromelist.txt (you may also need toolkit.jar for about:plugins, but I don't recall).

That should be all the bare essentials. The .jar files themselves could be stripped down alot also, but I don't care about 400+k enough to do the job of stripping them down, heh. They shouldn't impede startup speed much if any, though, because they are already indexed by .rdf files and are relatively small.


Shelumi`El
Jordan

S.D.G

Hmm...my About K-Meleon works fine, but not the About plugins. How does the 734 build About Plugins and scrollbar work fine without these? Does it get that info from embed.jar which I didn't find in the Mozi build?

LOL...All this time using KM I never knew typing "about:" brought up that info before.

Yeah, I took the files needed from embed.jar and put them in a newer classic.jar, but they are the same thing in essence. If you wanted to you could just take the whole chrome directory from a vanilla K-M 7.1 and copy it to the 1.2.1 / 1.3 directory, but the default embed.jar doesn't have all the files in it necessary to support about:config correctly, that's the main reason I switched them.


Shelumi`El
Jordan

S.D.G

Oh OK. The scroll bar came back when I put back toolkit.jar. And About plugins came back when I put back comm.jar. Hasn't effected startup time.

Because of the user32.dll errors in the 1.2.1 & 1.3 versions, I decided to try the latest k-meleon.exe from the 1.2.1 build in the 1.2b directory and was pleasantly surprised that it seems to work well. I had to also use the latest macros.dll from the 1.2.1 build because I got some crashes using the new exe with the other macros.dll on some of my macros. Also, bug 266(multiple save instances) still appears. But the following that I tested works:

ID_NAV_FORCE_RELOAD seems to be recognized.
ID_FILE_SAVE_FRAME_AS.
RETURN-only URL browsing(URL history scrollable w/o invoking URL untill RETURN)
The Combobox displays the correct user agent instead of blank.
* The new BOOKMARKS KEYWORD & QUICKSEARCH(%s)with bookmarks.dll from 1.2.1*

I haven't tested the others listed on MonkeeSage's page.

jsnj:

The bugfix for 266 is the only mozilla dependent change, all the rest of the changes will work no matter which mozilla you use (they should anyway, lol).

For 266 you only need three .dlls from the components directory of one of my installs:

embed_lite.dll
embedcomponents.dll
webbrwsr.dll

Just copy them over the ones from whatever mozilla you're using, and then 266 should be fixed as well.

Ps. My build of embed_lite.dll doesn't have anything to do with 266, but it writes out history.txt every 1 url, as opposed to every 10, so history(View) is always current.


Shelumi`El
Jordan

S.D.G

MonkeeSage,

I think I've fixed everything I can for now. Here's the list of everything I fixed:

347 - Suppress bogus invalid image message
306 - Remove "URL:" from URL bar
313 - Prevent URL bar dropdown autoselect when the URL bar has focus
381 - Add Force Reload command
297 - Fix Save As filename/filetype determination
387 - Add Save Frame As command
289 - Add URL bar nickname (bookmark keywords) lookup functionality
425 - Allow dashes and dots in global history incremental search
432 - Fix bookmarks file indentation (backpatch)
74 - Make plugin name lookup case insensitive
376 - Add aliases VK_PAGE_UP/VK_PAGE_DOWN for VK_PRIOR/VK_NEXT
433 - Make preferences browser id name combo list match current setting
281 - Make moving the mouse wheel cancel autoscrolling

The combined fix for 297/387 very likely fixes 202 as well.

Here are the major bugs I would like to see fixed but involve DOM or other Mozilla stuff which I don't know about:

12 - New windows steal focus when a new URL load is completed
29 - No autoscrolling for frames
105 - Reload frame command
288 - Form input fields are sometimes lost when returning to a page via back

By the way is Mozilla 1.3 any faster than 1.2/1.2.1 ? Also 1.4a is out, note 1.4 will be the last release before major Mozilla suite changes occur. See MozillaZine for more about this.

asmpgmr:

12 - I'm looking into what's up with this right now, but I'm thinking it may be because of the way they set up the window open states (open, opennew, openbg) in the macros; or the problem might be in ID_NEW_BROWSER ( which is CMfcEmbedApp::OnNewBrowser() ). Got to figure out if it happens for both, or for only one, and if the latter, which one; then check to see if there is a call to focus the new browser view after it is created in either of those functions


29 & 105 - Beyond me...I'm going to mess with using some of the stuff in ViewContentContainsFrames() and other functions in BrowserView.cpp, but I doubt I can do anything about either of these. I'm going to send a copy of the K-M source to my brother also, and see if he can come up with anything.


288 - No idea...I looked at the K-M function for back, and it looks like it is only sending Mozilla the nav back signal, could be a Mozilla bug?


I haven't noticed any speed difference at all in 1.2.1 / 1.3 -- actually if anything 1.2.1 might be a bit quicker. The only real reason I use 1.3 over 1.2.1, is because 1.3 has better javascipt and DOM support it seems like. Mabye it's just me, but it seems like sometimes 1.2.1 wouldn't catch MouseOut, or wouldn't do the OnLoad in the body tag, or won't render a CSS+javascript (.dhtml) block right on first load, &c.

I'm about to go back to 1.2.1, though, unless they get themselves together a bit more on 1.4, because the last week or so of 1.3 CVS have had their gklayout messed up--it doesn't read the preference for no image animation, untill after the page is reloaded (and some--seemingly randomly--images still flash and move even then!)...and I HATE seeing all these flashing / moving emoticons all over the place on msg boards I visit (p.s., yes I checked that they were regular .gif images, because imagine the horror of thinking they somehow made quicktime movies really tiny and everyone was using them all over the place lol). I think it has something to do with their new auto image sizer thing rendering after (and regardless of) the page properties as determined by the prefs, but just a guess.


I'm pulling the MOZILLA_1_4a_RELEASE tree right now (there is no MOZILLA_1_4a_BRANCH yet). The 1.3 installer will be replaced by the 1.4a installer, assuming it builds and K-M plays right with it. I'll post when it is up, but it will probably be a few hours, at least.


Shelumi`El
Jordan

S.D.G

MonkeeSage,

12 - The focus stealing definitely has something to do with opening a new window and is not macro related. It's most noticeable when a link opens in a new window - the focus is switched immediately which is correct, then a second time when the page is loaded which is annoying if you have switched away.

288 - I guess this may well be a Mozilla problem. I haven't used Mozilla in several months now so I'm not sure if this happens with Mozilla or not.

The big problem with Mozilla (besides xul) is that they crank out releases much too often (+0.1 every 3 months), adding too many features, not fixing enough bugs, and not near enough concern for optimizing the code. Basically it's a very big project that needs better planning and management. Apparently the plan is to address these issues after 1.4 and it's about time. If they would only scrap xul then they would definitely be on the right track.

Bug 239 where Read nsDiskCacheStreamIO appears in the status bar is not really important but it makes KM look kind of tacky and beta-ish. I could swear this went away with one of the earlier Mozi-Meleon builds but if it did ever go away, then it's back in full force.

I did some checking and the focus stealing problem occurs with view source as well so it's a general issue with opening a new window in the foreground. I looked through the code and couldn't find what causes the focus to change the second time.

asmpgmr:

I'm not positive, but I think this might be the problem.

MfcEmbed.cpp, in OnNewBrowser():

//Load the new window start page into the browser view
pBrowserFrame->SetFocus();
pBrowserFrame->m_wndUrlBar.MaintainFocus();


I'm thinking that the MaintainFocus() is what is actually stealing the focus; but the problem is I'm not sure why they are using it. Mabye Mozilla automatically focuses after it is done loading and they are using it to steal the focus back from Mozilla after Mozilla steals it when it is done loading?? Not really sure, but I'm going to try removing the MaintainFocus line and see what happens. I'll let you know the results.


Shelumi`El
Jordan

S.D.G

MonkeeSage,

I don't think that's it. I think OnNewBrowser is called for a new invocation of K-Meleon, there's stuff in there to load the home page or blank.

There is a comment "mozilla always tries to steal focus twice" in BrowserFrm.h in function ReturnFocus but that only seems to be called from OnUrlKillFocus in BrowserView.cpp. I'm not sure what action triggers the message (CBN_KILLFOCUS) which ultimately calls that function.

MonkeeSage,

You may be interested to know that newly opened bug 442 is yet another frame related bug. Title tooltips are not positioned correctly in frames. Mozilla simply avoids these issues - title tooltips are never displayed (also avoiding bug 347), there is no autoscrolling at all, and reload frame is done via javascript. Lets not forget they didn't even support Save Frame As. Frankly I think very little effort was put into the original mfcembed code, they had their heads too far buried in the xul sand.

jsnj,

About Read nsDiskCacheStreamIO, this message isn't generated by K-Meleon, it comes from the Mozilla code (necko.dll) via an embed.jar properties file (necko.properties) and is generated via message substitution (Read %S). In fact I searched the Mozilla source cross reference site and couldn't even find the string "nsDiskCacheStreamIO" anywhere in the Mozilla source code, only the function of the same name. Apparently it's embedded in necko.dll via some other means but a hex editor shows it's clearly there. Anyway the message just indicates the data is being read from the disk cache instead of being fetched from the net. I don't remember if Mozilla displays this or not, if not then it's likely being supressed via some convoluted xul means.

It's not visible in Mozilla & Phoenix. I don't remember ever seeing it in KM v0.6 though. Strange.

MonkeeSage,

Is the "wait" command no longer included in your latest macros.dll?

jsnj:

It wasn't for a bit, cause Ulf nixed the proposal, but I stuck it back in with the other new macro commands I added recently ( http://monkeesage.d2g.com/KM-Macros.htm ).

Try one of the latest installers (new macros.dll needs some core support too for the tbtoggle / set commands, that's why I say get a whole installer).


Shelumi`El
Jordan

S.D.G

oops...

http://gratisDei.com/KM-Macros.htm

The functionality of toggling toolbars on and off can already be done with the macro id function: id(num) where num is between 2000 and 2050.

asmpgmr:

Very interesting! Thanks for the tip! There are so many undocumented little goodie packed in!


Shelumi`El
Jordan

S.D.G

MonkeeSage,

Forget all the newbies and dummies, did you get anywhere with the new window focus stealing issue ? My best guess is that it has something to do with some win32 message which is generated the first time a page loads in a newly displayed window.

MonkeeSage,

A minor change in the ns_bookmarks_utils.cpp I want to try - at the very end of the file some code is commented out which would clear the status bar when the cursor is on separators and popup submenus in the bookmarks menu. The comments say this doesn't always work but I don't see any reason why it shouldn't and even so it shouldn't cause any harm so uncomment the following three lines:

else {
kPlugin.kFuncs->SetStatusBarText("");
}

asmpgmr:

I tried commenting out the MaintainFocus but it didn't seem to matter. I don't have much idea about windows API messages, so I'm prolly not going to be much help from what you described.


I've been working on a bug 23 fix / workaround...what I was trying to do was to get the text of prefs.js into a global variable, _before_ K-M did its exit stuff, then write the buffer of that variable as prefs.js _after_ its exit stuff was done. Didn't work, because I can't figure out _where_ to set the variable buffer....every place I try it, it ends up with the buffer after K-M already has discarded the changes to the prefs file...I'm going to look at how the javascript that about:config uses sets prefs that stick accross sessions and try doing something like that on the prefs file before it is changed.


Here's the build of the bookmarks plugin with that change:

http://monkeesage.d2g.com/bookmarks.dll


Shelumi`El
Jordan

S.D.G

MonkeeSage,

I wouldn't consider bug 23 valid, some prefs (like the session history) aren't written out until exit and this shouldn't be overriden. The about:config code likely uses the Mozilla preferences service interface.

MonkeeSage,

The bookmarks plugin change works just as expected, I wonder what prompted the code to be commented out originally ? I suppose the favorites and hotlist plugins should be updated as well (I only use the bookmarks).

asmpgmr:

I take bug 23 as extending to external edits. For example, if I open prefs.js in an external text editor w/ K-M open, and change a preferance I added myself that is completely meaningless to K-M, like

user_pref("browser.urlbar.autoFill", true);

Changed to:

user_pref("browser.urlbar.autoFill", false);


Then I exit K-M and check the file it is changed back...I haven't checked that this is true for the preferance panel.

I have a fix that solves this and allows for external edits, but for some reason it will not allow a line to be removed, only altered.

In BrowserViewUtils.cpp:
-----------------------------------
void CBrowserView:eleteTempFiles()
{
for (int x=0;x<m_tempFileCount;x++) {
DeleteFile(m_tempFileList[x]);
delete m_tempFileList[x];
}
if (m_tempFileCount > 0) delete m_tempFileList;

ReadPrefs();
}


void CBrowserView::ReadPrefs()
{
const char *filename = theApp.preferences.profileDir + "prefs.js";

nsCOMPtr<nsIPref> prefs(do_GetService(NS_PREF_CONTRACTID));
nsCOMPtr<nsILocalFile> prefFile(do_CreateInstance(NS_LOCAL_FILE_CONTRACTID));

prefFile->InitWithNativePath(nsDependentCString(filename));
prefs->ReadUserPrefs(prefFile);
theApp.preferences.Load();
prefs->SavePrefFile(prefFile);
}



BrowserView.h:
----------------------
void DeleteTempFiles();

void ReadPrefs();



PreferencesDlg.cpp
----------------------------
if (NS_SUCCEEDED(rv)) {
nsCOMPtr<nsILocalFile> prefFile(do_CreateInstance(NS_LOCAL_FILE_CONTRACTID));
rv = prefFile->InitWithNativePath(nsDependentCString(filename));

prefs->ReadUserPrefs(prefFile);
theApp.preferences.Load();
prefs->SavePrefFile(prefFile);
}


The prefs->SavePrefFile(prefFile); line causes it to register all the changes that were just loaded from the edited prefs.js file, as well as write it out again. Somewhat redundant, but I don't see any other way of registering the changes short of setting each one manually with prefs->SetBoolPref(), &c.

http://monkeesage.d2g.com/k-meleon.exe


I'll change the other plugins as well to reflect the bookmarks change, works fine for me as well, dunno why it was commented or what the heck the comment is supposed to mean about working fine except under win32 (???).


Shelumi`El
Jordan

S.D.G

Scratch that part in PreferencesDlg.cpp, it is already writing the file above that.