[Needs Testing] Patch for Bug# 243078-Native Theme Rendering

[campcove]

There is a comment #187 in the bug 243078 that bsmedberg is concerned about an issue with menu.xml. I can't understand it but it may have something to do with css. I don't know if he is speaking on the behalf of a larger group.
Read if further interest.

[grantaw]

When I click on a menu item (e.g., "File" or "Edit"), the text doesn't move. I'm using XP Classic.

[BoxerBoi76]

Isn't there a border line missing in the print preview view on the bottom of the toolbar? Seems to me there is but I could be wrong.

BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051012 Firefox/1.4.1 ID:2005101216

BoxerBoi76

[BoxerBoi76]

When I click on a menu item (e.g., "File" or "Edit"), the text doesn't move. I'm using XP Classic.

I'm hoping Silver can fix that in the trunk patch he's going to be working on. He is aware of this issue...

BoxerBoi76

[polidobj]

There is a comment #187 in the bug 243078 that bsmedberg is concerned about an issue with menu.xml. I can't understand it but it may have something to do with css. I don't know if he is speaking on the behalf of a larger group.
Read if further interest.

From what I can tell the problem he speaks of is the regression where favicons can end up being too big.

[X-Trace]

Why entries like that in userChrome.css don't change the classic theme anymore since this bug landed on the branch?

menupopup, popup {
-moz-border-top-colors: #666666 !important;
-moz-border-left-colors: #666666 !important;
-moz-border-right-colors: #666666 !important;
-moz-border-bottom-colors: #666666 !important;
padding: 0px !important;
border: 1px solid !important;
background-color: #F9F8F7 !important;
background-image: url(menuback.gif) !important;
background-repeat: repeat-y !important;
}

[X-Trace]

Bookmark favicon's are in original size and not resized to 16x16

[polidobj]

I figured out a small change to the CSS to eliminate the large favicon problem. It seems to work when I put this in my userChrome.css:

Code: Select all

 .bookmark-item .menu-iconic-left > .menu-iconic-icon {
   width: 16px;
   height: 16px;
   -moz-padding-start: 0px;
 }

I got it from browser.css which I changed:

Code: Select all

 .bookmark-item > .menu-iconic-left > .menu-iconic-icon 

to

Code: Select all

 .bookmark-item .menu-iconic-left > .menu-iconic-icon

But I don't know enough about the code to know if this will break something somewhere else.

EDIT: if that rule isn't specific enough this works too:

Code: Select all

.bookmark-item > stack > .menu-inner-content > .menu-iconic-left > .menu-iconic-icon

[old zeniko]

@X-Trace: You'll have to add -moz-appearance: none !important; to get around the native menu drawing code (which doesn't allow further modification through CSS).

[chrisv5]

I figured out a small change to the CSS to eliminate the large favicon problem. It seems to work when I put this in my userChrome.css:

Code: Select all

.bookmark-item > stack > .menu-inner-content > .menu-iconic-left > .menu-iconic-icon {
   width: 16px;
   height: 16px;
   -moz-padding-start: 0px;
}

works like a charm for me
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051013 Firefox/1.4.1 ID:2005101305

[mcm_ham]

Just a notice that all bugs are meant to be completely fixed by 23 October. Doesn't leave much time to resolve the implications of fixing this bug, including making it compatible with themes designed for beta 2.

Schedule

[Jweb_Guru]

It's not that hard to make themes compatible with it without the menu.xml change, and even with it it's not too bad. More importantly, themes have to be compatible with Firefox, not the other way around. That particular aspect is one that doesn't really matter for 1.8rc1.

James is going to try to fix all the regressions by Friday night; if not, there are alternative patches, and his menu.xml stuff will just have to be backed out and replace with a less visually perfect patch.

If you're talking about the '-moz-appearance:menuitem' not working well with current themes, that just requires adding a single line. This should not be a major issue with theme developers, and is the whole point of the bug.

[a;skdjfajf;ak]

If this fix should be backed out, then IMO the 'Wallpaper' should go as well. We will see far more complaints from the 'Wallpaper' than we will see from the themers fixing up the themes to work with this patch.

The whole thrust of this patch, and the 'Wallpaper' was to make things more IE like. I've been lurking and reading these forums for over a year, and I don't recall anyone complaining about the UI of the 1.0.x Firefox.

As noted in the bug, if this is backed out 100,000,000 users will be 'disappointed', well if this gets the axe, might just well remove the 'Wallpaper'..and the 100,000,000 users will never know the difference.

[mcm_ham]

I was really just meaning to link the notice from the developers site just so James was aware in case he missed it. I haven't been following the bug closely or read the code yet so was just going by Mozilla policy that all changes that could impact themes or extensions are meant to be finalized by the last beta, but if it's as simple as you indicate I guess they may make an exception.

[X-Trace]

For a long shot (on the way to FF 2.0), wouldn't it be better to deliver two themes (a classic one and a modern one), instead of making multifunctional themes with different appearance on different systems?

And another question: Is there now a simple way to include bug 216266 only affecting the classic look, since modern look on XP luna seems to be worse with it. Now I'm not that familiar with the code so see side effects or to verify, if it is an optimal solution. Maybe that's because I don't have a list of all possible keywords.