User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 StumbleUpon/1.906 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 When you have set up another search engine in the integrated google search box and then decide to remove the search box by dragging it to the Customize Toolbars dialog you get an ugly looking search box in the Customize Dialog Reproducible: Always Steps to Reproduce: 1.Go To Google Search Box and add another engine (for example IMDb) 2.Go View -> Toolbars -> Customize... and remove the searchbox Actual Results: An ugly looking search box in the Customize Toolbars dialog Expected Results: A beautiful searchbox, perhaps with the standard Google icon
*** Bug 241364 has been marked as a duplicate of this bug. ***
confirmed linux gtk2 trunk cvs 20040424 firefox, didn't need to add an extra engine to see this
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
this isn't a theme issue actually, seen on multiple themes. I could swear I've seen this before, but that might be on IRC.
*** Bug 247031 has been marked as a duplicate of this bug. ***
Summary: Removing custom-made search boxes gives ugly graphics in Customize Toolbars dialog → Search box is ugly in Customize Toolbars dialog
Probably related to bug 250355
(In reply to comment #6) > Probably related to bug 250355 Not necessarily, but that may be part of it. The main problem i see is that the search icon/dropmarker thing is actually a XUL button element, which is why it looks like it does in the Customize Toolbars window. It looks "correct" on the toolbar because of the #searchBarDropMarker binding on #search-proxy-button in browser/content/browser/browser.css, which, for some reason, it does not pick up in the palette. I think i attempted to visually fix the problem via the theme a little while back, but couldn't quite get it to work out as well as it did in my own theme. I may give it another whirl, unless someone can truly fix the underlying problem. Mike, I mentioned it before in bug 227745 comment #2, but never filed a bug on it.
The customization dialog doesn't know about the search binding stashed in content/browser.css.
surely we're not going to ship this broken?
Comment on attachment 154073 [details] [diff] [review] patch Yeah, OK, although I filed 255836 on what I deem to be bogus dependencies on the browser. This will do for 1.0. Can you make sure it doesn't break thunderbird though first? I'm not sure how the first include isn't...
14 years ago
Flags: blocking-aviary1.0? → blocking-aviary1.0+
(In reply to comment #11) > (From update of attachment 154073 [details] [diff] [review]) > Yeah, OK, although I filed 255836 on what I deem to be bogus dependencies on > the browser. This will do for 1.0. Can you make sure it doesn't break > thunderbird though first? I'm not sure how the first include isn't... > Firefox is the only app that uses the toolkit/ version, every other app has forked its own.
Thunderbird and Sunbird forked their own version because they had to, not because they wanted to. See Bug 250793 as an example. We should fix this centrally to make the forking unnecessary.
checked in on branch for 1.0, not sure if we want to fix this on trunk or just fix this better instead.
Whiteboard: [have patch] → fixed-aviary1.0
*** Bug 255024 has been marked as a duplicate of this bug. ***
I think we should resolve this and move any further work over to the more general problem at bug 250355
marking FIXED, we'll deal with the "right" fix in other bugs.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.