422228 - Cross-OS theme development nearly impossible for Mac OS X

Status: RESOLVED WORKSFORME

(Firefox :: Theme, defect)

Description

[KLB]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: Firefox/3.0b4

Developing Firefox 3.0 themes based the default Windows theme that also work on Mac Firefox is nearly impossible even though the same theme can be made to work on Windows and Linux quite easily.  In particular there appear to be some legacy Firefox 2.0 objects in Mac Firefox that are not in Windows or Linux Firefox.  For instance the most noticeable issue are legacy back & forward button drop buttons that appear beneath their respective back/forward button.  There are also issues with Mac Firefox overriding "-moz-appearance: none;" instructions for buttons and menulists and using Mac system objects instead.

Most of us who develop/maintain Firefox themes do not have multiple OSes that we can use to make our themes fully cross OS compatible.  Those that do have a Mac and Windows boxes very few are going to have an inclination to build their themes twice just to make them compatible with Windows/Linux and Mac.  Mac Firefox XULs and chrome in general need to be harmonized with Windows and Linux versions of Firefox so that one can start with any OS theme and build a custom theme that is cross OS compatible without going to extreme measures.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.



See the MozillaZine discussion at http://forums.mozillazine.org/viewtopic.php?t=635088 for more details on this issue and efforts to make a cross OS compatible theme.

Comment 1

[KLB]

Attachment: Screen capture comparison of windows based theme on Mac and Windows

Screen capture comparisons of the most problematic issues with making a Windows theme compatible with Mac OS.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

The back/forward issue is covered in bug 414445. To all the other parts I cannot give any statement.

Comment 3

[Stefan [:stefanh]]

> Screen capture comparisons of the most problematic issues with making a Windows
> theme compatible with Mac OS.

Hmm, regarding 2: I think if you want menus/menuitems look the same on all platforms you'll need to do the alignment (and the styling) yourself. The alignment of the icons should be like that on mac. In this case, wouldn't the same complaint be valid for windows if you where on mac and where trying to make it look the "same" on windows?

Comment 4

[Stefan [:stefanh]]

Ah, you're using -moz-image-region. Sorry, yeah, that's an issue. I thought it
was  about the alignment :-)

Comment 5

[Stefan [:stefanh]]

(In reply to comment #4)
> Ah, you're using -moz-image-region. Sorry, yeah, that's an issue. I thought it
> was  about the alignment :-)
> 

-moz-image-region issue is covered in bug 418774, btw

Comment 6

[Stefan [:stefanh]]

KLB,

Regarding 3 and 4: Please provide the css you use. It's pretty hard to see what's going on here without knowing exactly what kind of style rules you're using.

Comment 7

[Stefan [:stefanh]]

I played a little bit with userChrome.css (using !important on everything) and looking at 3, I think you have overruled the "display: none;" on .menulist-dropmarker. The problem here is that it's not enough to using "-moz-appearance: none;" for the menulist alone. The .menulist-dropmarker is a dropmarker that gets it's current style from dropmarker.css, so you need to use "-moz-appearance: none;" on that as well. I can't reproduce the button problem, I can get rid of the native styling for buttons with "-moz-appearance: none;" That is, one could argue that it's a problem that removing the native styling makes the button vanish completely (no non-native styling to fall back to). But iirc we do this in a lot of places.

Comment 8

[KLB]

Stefan,

If you use the default Windows theme, or any other custom Windows based Firefox 3.0 theme you will get the same problems. Another example of this problem can be seen at: http://www.takebacktheweb.org/themes/stuff/win-default-theme.png

In regards to using ".menulist-dropmarker" and "-moz-appearance: none;" for menulist alone, this completely works under Windows and Linux. Adding the instruction to the dropmarker.css file would be redundant (at least in Windows & Linux). If it is not redundant in Mac OS, then this would be an example of inconsistency between Windows/Linux and Mac OS.

I'm working on a new test version of my theme and will see what the "display:none" instruction does on Windows, but I suspect this will break themes on Windows.  I think, but not sure, that "display:none" is needed because the ".menulist-dropmarker" is actually turned off in Mac OS and a system button is used instead, which is the problem. I'll post a link to the new test version of my theme which Mac OS users can test shortly.

Comment 9

[KLB]

I played with the "display:none" for dropmarkers in Mac OS and like I expected, it disabled the dropmarker in Windows leaving what basically appeared to be a plain text box.  This reinforces my contention that Mac Firefox is inappropriately ignoring style rules and overriding with system buttons.

I have just uploaded the latest test copy of my theme to: http://EnvironmentalChemistry.com/classiccompact.jar

This test version includes some changes that may address issue #4 (missing border on options tab). I also specified "border-right:0px" to ".menulist-dropmarker" to see if this would have any impact in Mac Firefox. I don't think it will, but it doesn't hurt in Windows.

Comment 10

[Stefan [:stefanh]]

(In reply to comment #9)
> I played with the "display:none" for dropmarkers in Mac OS and like I expected,
> it disabled the dropmarker in Windows leaving what basically appeared to be a
> plain text box. 

I think you misunderstood me (or I was unclear). What I ment was that you should use "display: inline;" (or don't do anything if you haven't hidden it), together with "-moz-appearance: none;" for the menulist dropmarker (since it has "display: none;" in pinstripe/global/dropmarker.css).

Comment 11

[KLB]

Here's the thing, "display:none" was only in the Mac theme. There are no "display" instructions in regards to dropmarkers in Windows themes. For me to need to add display instructions indicate that there is indeed a problem with Mac Firefox not playing nice.  The purpose of this bug report is to point out that having to use kludged work arounds like adding "display:inline" would be, is not tenable. If I create a set of instructions that work identically in Windows and Linux Firefox then they should also work identically in Mac Firefox without modification. This is especially true where "-moz-appearance: none;" has been set to over ride OS specific styling (as I have done with dropmarkers).

Comment 12

[Stefan [:stefanh]]

So, what you ask for is basically that the default themes should have the same set of style rules for the same set of elements/classes/id's on all platforms - especially when it comes to "-moz-appearance" rules (no platform should have a different set of "native" style rules than the others)?

Comment 13

[KLB]

There can still be OS specific styling with a unified code base for themers especially in the instances pointed out in my bug report.  There is absolutely no straight faced reason to justify why different code is necessary for dropmarkers. The whole purpose of "-moz-appearance" is to allow OS specific styling and "-moz-appearance:none" is supposed to override OS specific styling.  Instead in this case, Mac Firefox is turning off dropmarkers and replacing them with some other object.  This makes no sense.

Comment 14

[KLB]

Upon rereading my last post, I realize it might be confusing so let me clarify what I intended.  

What I am calling for is a unified XULs and chrome.  This means that the same object names, classes and IDs would be used across all OS versions of Firefox and they would control the same things across all OSes.  The actual default theme for each version of firefox might use different style instructions, but if a themer, used a style instruction like the following example, it would behave in an identical fashion in all versions of Firefox:

--Code example--
dropmarker {
  -moz-appearance: none;
  width: 16px;
  height: 16px;
  -moz-box-align: center;
  -moz-box-pack: center;
  border: 2px solid;
  -moz-border-top-colors: ThreeDLightShadow ThreeDHighlight;
  -moz-border-right-colors: ThreeDDarkShadow ThreeDShadow;
  -moz-border-bottom-colors: ThreeDDarkShadow ThreeDShadow;
  -moz-border-left-colors: ThreeDLightShadow ThreeDHighlight;
  background-color: -moz-Dialog;
  padding: 1px;
  list-style-image: url("chrome://global/skin/arrow/arrow-dn.gif");
  -moz-image-region: auto;
}
--end Code Example--

What is happening right now is that in the Mac theme "dropmarker" is being turned off via "display:none" and some other object that is unknown to me and does not exist in Windows or Linux versions of Firefox is being used instead. Unfortunatly this is completely incompatible with Windows and Linux because declaring "display:none" would totally disable the dropmarkers in those OSes.

Again, the whole purpose of "-moz-appearance" was to allow for a simple way to declare whether to use OS specific styling/objects or to use OS independent style instructions as I am trying to do in the above example.

Comment 15

[Mike Connor [:mconnor]]

There's absolutely no way we'll solve this in any non-disruptive way, so way way way out of scope for Fx3.  Main issue is that the base themes don't get replaced wholesale by other themes (we keep hitting other issues for this) so its not really a good situation.  Not sure the benefits are there to change this behaviour in any case, but now isn't the time to argue it.

If you want to override display: none, fwiw, you could use display: normal !important iirc...

Comment 16

[KLB]

I think I have resolved issue number two, three & four from my attachment with the following solutions:

Issue #2)
Since "-moz-image-region" isn't supported in the Mac widget that controls the main menu list, I replaced the image call to a single PNG with multiple icons and the use of "-moz-image-region" with separate folder and bookmark item icons (from browser.css):

/* ::::: bookmark items ::::: */

.bookmark-item  {
  list-style-image: url("chrome://global/skin/icons/menu-item.png");
}

.bookmark-item[container] {
  list-style-image: url("chrome://global/skin/icons/folder-closed.png");
}

.bookmark-item[container][open] {
  list-style-image: url("chrome://global/skin/icons/folder-opened.png");
}


Item number 3)
I need confirmation that this one was resolved, but I set the right margin for the drop marker's hbox to zero.

Item number 4)
I fixed the tabs on the option panel by setting "-moz-appearance" to none for all "tabpanel" and "tab" related entries and manually styling borders, padding, etc. for the tabs. These entries are found in "tabbox.css".

Comment 17

[KLB]

Full documentation as to how to make a theme compatible on Mac OS and Windows/Linux at the same time when starting with a Windows based theme can be found at: http://forums.mozillazine.org/viewtopic.php?t=635088&start=30

The only binding changes required all relate to the forward and back button dropmarker issue.  All other issues can be resolved with CSS style changes, particularly setting "-moz-appearance" to "none" and manually styling objects.

Comment 18

[Dão Gottwald [:dao]]

The back/forward button issue has been addressed in bug 518533.

Comment 19

[Markus Stange [:mstange]]

The wizard numbers have been removed by bug 485235 and the -moz-image-region in menus issue has been fixed by bug 418774.

Comment 20

[[e-mail]]

Are radio and checkbox menuitems an issue? They appear to be completely different in all in-tree themes:
* Windows uses appearance on the menuitem and on the check/radio indicator
* Linux uses appearance on the menuitem, which presumably draws the indicator
* Mac uses a weird background overlay image to display the indicator
* OS/2 uses an image on the check/radio indicator

Comment 21

[Jared Wein [:jaws] (please needinfo? me)]

I think this bug can be closed now.