Search bar looks strange when on customize toolbar palette

RESOLVED FIXED in Firefox 3

Status

()

Firefox
Search
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: stevee, Assigned: philor)

Tracking

({polish, regression})

Trunk
Firefox 3
x86
Windows 2000
polish, regression
Points:
---
Bug Flags:
blocking-firefox2 -
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

11 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1) Gecko/20060918 BonEcho/2.0 ID:2006091813

1. New profile, start firefox
2. Right click on toolbar > customize
3. Drag the search bar to the palette
4. Observe search bar in palette

Expected:
Search bar looks normal

Actual:
Search bar looks strange; too tall and endcap is odd

Screenshot to follow
(Reporter)

Comment 1

11 years ago
Created attachment 239169 [details]
screenshot of search bar on customize toolbar palette
Keywords: regression
Not sure that this should actually prompt an RC2 on it's own, but if the fix is simple and we end up having an RC2 for some other reason, we should probably look at taking a fix for this...
Flags: blocking-firefox2?
Target Milestone: --- → Firefox 2

Comment 3

11 years ago
-> bug 353320
*** Bug 353320 has been marked as a duplicate of this bug. ***

Comment 5

11 years ago
(In reply to comment #4)
> *** Bug 353320 has been marked as a duplicate of this bug. ***
> 

Incidentally, the location bar when dragged into the palette is a little messed up too, though not as bad. The location bar in the palette does not show the dropdown and the 'Go' endcap. Is it worth filing another bug?
(In reply to comment #5)
> Incidentally, the location bar when dragged into the palette is a little messed
> up too, though not as bad. The location bar in the palette does not show the
> dropdown and the 'Go' endcap. Is it worth filing another bug?

It's always worth filing another bug, yes. Whether or not that bug is worth nominating for blocking is another question (I wouldn't say we'd block on it) but we should have it on file so it eventually gets fixed.

Comment 7

11 years ago
Not taking for FF2.   
Flags: blocking-firefox2? → blocking-firefox2-
*** Bug 353848 has been marked as a duplicate of this bug. ***

Comment 9

11 years ago
(In reply to comment #6)
> (In reply to comment #5)
> > Incidentally, the location bar when dragged into the palette is a little messed
> > up too, though not as bad. The location bar in the palette does not show the
> > dropdown and the 'Go' endcap. Is it worth filing another bug?
> 
> It's always worth filing another bug, yes. Whether or not that bug is worth
> nominating for blocking is another question (I wouldn't say we'd block on it)
> but we should have it on file so it eventually gets fixed.
> 

I have filed Bug 353438 for this. ;)
Here's how it breaks in Win98.  Same general behavior, somewhat different appearance.

http://img157.imageshack.us/img157/2663/sp3220060930140016ob2.jpg
Created attachment 240745 [details]
shows Search Bar item in Customize Toolbars palette on Win98, looking strange

Comment 12

11 years ago
CCing self.  Thought this weird look might be a screwed up FF install on my machine, but turns out it's a bug with FF2 itself.  Certain themes seem to fix it, eg. macbirdgraphite (https://addons.mozilla.org/firefox/3968/).  I'd probably try and fix this, but, well... I can't be bothered.  Leave it to the theme people.
Keywords: polish

Updated

11 years ago
Duplicate of this bug: 373354
(Assignee)

Comment 14

11 years ago
searchbar.css uses |toolbar[stuff] .search-go-yadda| as selectors to manage the scaling differences between text and icon mode, so those selectors don't apply in the palette. Instead, it needs to apply all the rules for icon mode with just |.search-go-yadda|, and then overrule them with |toolbar[mode="text"]|, without regressing any of bug 353149, bug 352681, bug 348138, or bug 351618 (which blame says were the causes of the current state).
Assignee: nobody → philringnalda
(Assignee)

Comment 15

11 years ago
Created attachment 258516 [details] [diff] [review]
Fix v.1

Hmm, a smart person probably would have looked at your fix for bug 353438 before figuring it out and patching it, not after.

Still, I like my approach better, since I know I for one wouldn't have guessed that I have to keep the id in customizeToolbar.xul in sync with a css file in browser/. Making it look the same everywhere except a mode="text" toolbar just feels safer than making it look the same on either a not([mode="text"]) toolbar or a palette-box.
Attachment #258516 - Flags: review?(mano)
(Assignee)

Updated

11 years ago
Status: NEW → ASSIGNED
Target Milestone: Firefox 2 → Firefox 3
Version: 2.0 Branch → Trunk
Comment on attachment 258516 [details] [diff] [review]
Fix v.1

But but.. this shrinks the space between the search button to its on-hover border (probably due to padding: 0px; rule).
Attachment #258516 - Flags: review?(mano) → review-
(Assignee)

Comment 17

11 years ago
Created attachment 262391 [details] [diff] [review]
Fix v.2

Pushed me into finally setting up a Windows build environment that could handle trunk (which I guess is a good thing) since I couldn't see what you meant, building it on Linux. Turns out, that's because Linux was broken, and didn't have any padding on the button before my patch, so I couldn't see it disappearing.
Attachment #258516 - Attachment is obsolete: true
Attachment #262391 - Flags: review?(mano)
Comment on attachment 262391 [details] [diff] [review]
Fix v.2

r=mano.
Attachment #262391 - Flags: review?(mano) → review+
(Assignee)

Comment 19

11 years ago
browser/themes/winstripe/browser/searchbar.css 1.17
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Assignee)

Updated

11 years ago
Flags: in-testsuite-
You need to log in before you can comment on or make changes to this bug.