Closed Bug 349418 Opened 18 years ago Closed 18 years ago

Bug 349079 breaks many 3rd-party themes

Categories

(Firefox :: Toolbars and Customization, defect)

2.0 Branch
x86
Windows XP
defect
Not set
major

Tracking

()

VERIFIED INVALID

People

(Reporter: sailfish, Unassigned)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060819 BonEcho/2.0b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060819 BonEcho/2.0b2

The binding and CSS changes implemented to fix bug #349079 break many existing themes (and possibly extensions with toolbars.) I don't wish to sound too critical but the method used seems like an inelegant way to solve what appears to be an text alignment problem with the menu toolbarbuttons. I say "appears" since bug #349079 looks like it was hastily written and rush through the system.

Reproducible: Always
Version: unspecified → 2.0 Branch
Would you mind to explain how so? This binding is Winstripe and Pinstripe specific and is only applied to the back & forward buttons.
It is most 3rd party theme designers desire to keep current with the default theme, especially when binding overlay changes occur since not doing so has been a cause for browser instability in the past. When I applied bug #349079 patches both the text and dropmarker alignment became skewed, along with the toolbarbutton text for the go-button and the go-search button. Also, while I cannot confirm the specifics with other 3rd party themes, here's a thread where's it's being discussed.
Sorry, here's the thread link:

http://forums.mozillazine.org/viewtopic.php?p=2441976#2441976
You know, you don't have to use the new binding at all. In fact, winstripe didn't have any special binding applied to the b&f buttons before this winstripe-change landed.

Closing as INVALID.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
As I explained, not including the binding then makes a theme out of sync with with whatever else in the browser (or extension) may expect that binding change to be there and, perhaps, cause browser instability by not being there.

It is not obvious why a binding change was necessary to implement what appears to be a text and/or dropmarker alignment issue? These types of issues can normally be solved with using different selector rules.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Summary: Bug 349079 Breaks many 3rd party themes → Bug 349079 breaks many 3rd-party themes
Order of elements in particular, and other little nits. The buttons still support the normal toolbarbutton api. Note we've been using a very different binding on mac for ages and it broke nothing as far as I can tell.

Closing this as INVALID again, please do not reopen unless you've a strong argument (or real-life examples other than I had coppied over one file and noticed unexpected results).
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → INVALID
I reopened it because you failed to adequately respond to my stated concerns and instead suggested a historically risky solution of excluding the binding. As far as different bindings not causing a problem on Mac, a more correct statement would be that is has not caused a "known" problem. Also, the PC is a different opsys so it probably isn't good to assume that what doesn't cause a problem on one platform automatically means that it won't in another.

read/ignore.
A custom binding does not need to be applied for other themes.  Applying a patch for a theme it wasn't intended for is going to result in weird behaviour, especially if used blindly.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.