Closed Bug 806583 Opened 8 years ago Closed 8 years ago

strange white border around textboxes appeared since some time in gecko 18

Categories

(Core :: Widget: Gtk, defect)

x86
Linux
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla19
Tracking Status
firefox17 --- unaffected
firefox18 + verified
firefox19 --- verified

People

(Reporter: aceman, Assigned: karlt)

References

Details

(Keywords: regression)

Attachments

(3 files)

Strange white border is rendered around all textboxes since some time in gecko 18. It is seen in Thunderbird (self compiled) and also official Firefox Aurora 18 from mozilla.org. It is there since that time.
This problem also appeared once in the past around July 1 but vanished several days after that. Now it reappeared and stayed for some weeks.

See the screenshot.

This is on Slackware linux 14, 32bit. Libraries up to date (latest Thunderbird trunk can be compiled/run on it). Running in a KDE3 desktop.
Last good nightly: 2012-09-28
First bad nightly: 2012-09-29

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=895f66c4eada&tochange=c09a0c022b2e

Found on Firefox nightlies with mozregression tool.
I can build Thunderbird from comm-central so if you have any tips on which patches to try to revert I can do it (just tell me the hg commands:)).
No real idea what could be causing this.
Assignee: nobody → karlt
What is the GTK theme?
Not sure, how can I find it out?
I use KDE3, but this TB/FF is run under a user that has never started any desktop environment. I su to the user from an xterm. So it may not have the proper defaults set yet. Please tell me what to check.
Yeah, it's not necessarily trivial to find out.
Check ~/.gtkrc-2.0 and /etc/gtk-2.0/gtkrc for a gtk-theme-name setting.
Look in ~ for the user of the TB/FF process, but the GTK2_RC_FILES environment variable may contain more files to check for the setting, including the session user's files.
GTK also looks for an XSettings daemon which can provide the theme.  Some desktops provide this daemon and each would have a different way of controlling the setting, but I don't think KDE3 has an XSettings daemon.
Those are the mechanisms I know.  Perhaps there are more.
There is no ~/.gtkrc-2.0 but /etc/gtk-2.0/gtkrc contains:
gtk-theme-name="GTK+"

No GTK2_RC_FILES environment variable, no XSettings daemon. This is KDE3 on Slackware 14.
Thanks.  I can reproduce with the built-in theme.
Status: NEW → ASSIGNED
Reverting http://hg.mozilla.org/integration/mozilla-inbound/diff/1556064f1c20/widget/gtk2/nsNativeThemeGTK.cpp
restores intended behavior (even though I've come to like the white border).
I suspect you'll get reftest failures if you revert that (since I think Matt added it to fix test failures)
Looks like the cause of reftest failures has been resolved elsewhere:
https://tbpl.mozilla.org/?tree=Try&rev=492b9d6d865d
Component: XUL Widgets → Widget: Gtk
Product: Toolkit → Core
Confirming comment 11 fixes the problem on TB trunk.
The changeset referenced in comment 11 shouldn't really have caused this bug, but this code was written assuming the clip_rect would never be larger than the entry widget's rect.

GtkEntry only sets this background on its own widget, so it doesn't make sense to draw outside the widget rect.
Attachment #678609 - Flags: review?(roc)
But it should not be necessary to draw extra space around a textfield/entry widget.  GtkEntry is implemented with its own window so it can never draw outside its bounds.  If our mimicking of GtkEntry is causing drawing outside the entry widget, then there is a bug somewhere else.
Attachment #678611 - Flags: review?(matt.woodrow)
Attachment #678611 - Flags: review?(matt.woodrow) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/29a7fc6e3930
https://hg.mozilla.org/integration/mozilla-inbound/rev/3523098f7911

I expect I can write a test to check that textboxes don't draw outside their bounds.

This bug should be affecting all themes that don't use Gecko's honors-transparent-bg-hint style property but our test machines might use that.
Flags: in-testsuite?
https://hg.mozilla.org/mozilla-central/rev/29a7fc6e3930
https://hg.mozilla.org/mozilla-central/rev/3523098f7911
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
Tracking 18, DLBI regression .
The test that failed here didn't fail on the test machines, but I checked it in anyway.  I assume Fedora 12 defaults to Clearlooks, which sets honors-transparent-bg-hint.
https://hg.mozilla.org/integration/mozilla-inbound/rev/b96d1860a248
Flags: in-testsuite? → in-testsuite-
Thanks, verified the fix in today's Thunderbird trunk.

We may want this in TB18 too.
Status: RESOLVED → VERIFIED
In Firefox 18 too of course. Please nominate the right patch for Aurora.
Comment on attachment 678611 [details] [diff] [review]
remove unnecessary extra space added for textfield/entry

We could take either patch as a fix on branch, but this is the one that restores the code to the state before the regression.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): dlbi
User impact if declined: extra white border with some GTK themes
Testing completed (on m-c, etc.): on m-c
Risk to taking this patch (and alternatives if risky): low
String or UUID changes made by this patch: none
Attachment #678611 - Flags: approval-mozilla-aurora?
Comment on attachment 678611 [details] [diff] [review]
remove unnecessary extra space added for textfield/entry

Approving the patch on aurora and adding "qawanted" , "verifyme" to help with verification here.
Attachment #678611 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Verified fix in Aurora:
Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20121114042011

Thanks a lot!
Marking as verified for 18 based on comment 28.

aceman, could you verify this is ok in 19 as well? (can't reproduce on ubuntu).
Yes, it is OK in Firefox Aurora 19 as downloaded from mozilla.org.
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.