Fortunately, I don't think anyone has to go through that timesome process of adding the profile dir file by file, because I found the reason for the problem: corrupted cache!
Thanks for your time though, read my reply on Travis Crump for more info. / David Jason Johnston wrote: > David Tenser wrote: > <snip/> > >> Thanks for the tip. I tried to create a new profile, and, very >> surprising for me, it does make a big difference! It's still pretty >> slow when initially loading the page (the address previously >> mentioned), but when alt-tabbing between windows, it repaints the page >> instantly now. >> >> How come?! >> >> What exactly is stored in the profile? Shouldn't the page renderer >> (Necko?) render a page the same way, regardless of what email settings >> that I have for instance? How can the profile affect the performance >> on the screen painting of websites? And an even harder question to >> ask, why is it just this page, and not every page? >> >> Of course, I'm sure there are other pages that has the same problem on >> this machine, but still... why? >> >> / David >> > > > Yes, this kind of thing shouldn't happen, but that's why we're all > running Mozilla test builds, isn't it, to help find these wacky things > and report them as bugs? > > Ideally the profile shouldn't affect rendering speed, but occasionally a > bad nightly build will slightly corrupt some file or add a bogus pref or > something else that causes a conflict in some obscure part of the > rendering code. Last month I found a bogus line in my prefs.js that > caused external javascript files to not load! :-0 (It's since been fixed.) > > If you have the time and the patience, what would be very helpful is to > try copying your old profile file-by-file into the new one, testing Moz > after each step, and see at what point the bad behavior returns. If you > can narrow it down to a specific file, you can file a bug report and > attach the file to it (provided it doesn't contain any sensitive > personal information ;-)). Then the developers will have a testcase to > go by, which often is the most important step. > > If you don't have time to do this, then I'm afraid whatever bug it is > will probably go unfixed, unless someone else happens to have the same > problem and does the legwork. > > --J >
