User-Agent: Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9b3pre) Gecko/2008011404 openSUSE/10.3 Minefield/3.0b3pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9b3pre) Gecko/2008011404 openSUSE/10.3 Minefield/3.0b3pre from over a few days I see no bottom borders of notebook/tab widget. I thinked it's gonna be fixed in a few days. I was wrong. Reproducible: Always Actual Results: bottom borders are missing Expected Results: everything ok

Probably a GTK issue? If so, please move to Widget: GTK.

Where? There's no Widget component and no GTK component...

Core :: Widget: GTK

If this is about the tab browser, is it then not a dupe of bug 412359 (no borders because no notebook)? Otherwise can you tell me where you see this? Maybe a screenshot?

Not in main window. In preferences window.

WFM... could it be a GTK theme issue?

No, silly. It worked few days/weeks ago. It must be a regression. I noticed it for Nodoka (current and SVN/GIT), Clearlooks (current and SVN), Rezlooks.

(In reply to comment #8) > No, silly. If you can't be polite, please leave our Bugzilla. Your habit of dropping "ping" noise into a dozen bugs at a time is also not welcome.

[[ please leave our Bugzilla ]] I'll not, because I'm a bug hunter. If I left "ping" somewhere, I wanted to tell you it's time to fix it.

Jakub, since we're having trouble reproducing the bug, it would help if you could figure out exactly which day this bug was introduced. Then we can look at what checkins went in between the two nightlies and try to guess which one introduced the bug. You can download nightlies from e.g. https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/01/ and use them to find a regression range.

(In reply to comment #10) > [[ please leave our Bugzilla ]] > > I'll not, because I'm a bug hunter. > > If I left "ping" somewhere, I wanted to tell you it's time to fix it. You don't seem to understand how we work. We're under no obligation to do anything at all, and saying "ping" in tons of bugs does absolutely no good at all except to annoy developers. Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html and understand these etiquette guidelines concerning Bugzilla. We expect all users on bugzilla.mozilla.org (including you) to follow them. Thank you for reporting all these issues, but please don't ignore the Etiquette. Thanks!

[[ Jakub, since we're having trouble reproducing the bug, it would help if you could figure out exactly which day this bug was introduced. Then we can look at what checkins went in between the two nightlies and try to guess which one introduced the bug. ]] 30/31 nightlies to check out :o ? You're crazy... I'll try to move .mozilla to .mozilla-bkp/etc to check if it's not my profile's problem.

I wasn't wrong. Something's wrong with my current profile.

> 30/31 nightlies to check out :o ? > You're crazy... If you use binary search, you only ends up having to test about 7 nightlies. Nothing crazy about that; we do it all the time. > Something's wrong with my current profile. Aha! Can you figure out which file in your current profile causes the bug to appear?

I don't know, but it's not important. My profile was earlier used by Firefox 2, and then I've migrated to Trunk.

Well, it's kinda important if *everyone* who migrates from Firefox 2 to Firefox 3 is going to experience the bug ;) If that's not the case, I'm fine with this bug being marked as WORKSFORME.

Listen, I had FF2 profile, then I've migrated to FF3, but sometimes I've ran FF2, because of my mistake. So it's not migrate bug.

I've found it! When browser.preferences.animateFadeIn is enable, bottom borders of notebook widget in preferences are missing. When it's disabled, everything is ok!

Ok, I know what is the problem - dimensions of Preferences window are too small for browser.preferences.animateFadeIn=true (notebook widget is CROPPED). PS: Should I file another bug about smooth JS on Windows and non-smooth on Linux?

still true.

Ah, this is just another case of the pref window being too small, right ? If true, it's a dupe.

being too small and "5 times smaller than small" are different cases.

This is same issue as bug 284414, but that one is on Windows, and this one is on Linux. The theme is the same: initial size calculation for these panes is just wrong...

Actually bug 284414 is not precisely the same. That one is about initial size. Bug 394299 has the fix for this 'cutoff' problem for Windows. The line that is relevant is: /* bottom-most box containing a groupbox in a prefpane. Prevents the bottom of the groupbox from being cutoff */ .bottomBox { padding-bottom: 2px; } Even better is: prefpane>.content-box{padding-bottom:4px} as not not all panes have a 'bottomBox', but all do have a '.content-box'.

Bug 394299 is for working around the cutoff problems on windows and bug 394433 is for the underlying issue on windows. Leaving dependency since you might want to use the same workaround it added for this case on Linux.

bah, the actual work around was added in bug 283697 so changing dependency