397723 - (proto) New Theme for Mac OS X

Status: VERIFIED FIXED

(Firefox :: Theme, enhancement, P1)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

This is a tracking bug for the new Mac OS X Theme for Firefox 3.

Comment 1

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Stephen's initial mockup of the main toolbar

Comment 2

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Prototype theme screenshot

Comment 3

[Alex Faaborg [:faaborg] (Firefox UX)]

Since this hit digg it looks like we will be getting a lot of traffic.  A
couple of notes for people who are curious:

-This is currently a mockup, not the final design
-We are taking visual integration seriously on every platform, but we are also
working on ways to create a design that is still uniquely Firefox, and
recognizable across all of the platforms
-Calling it an identity crisis is going a little far since most apps try to
match the OS they are running on
-While we are not going to exactly match Safari, a massive number of mac users
have written in to request that we put greater effort into visual integration
with OS X for Firefox 3

Comment 4

[Jesse Ruderman]

http://digg.com/apple/Proposed_Firefox_3_Theme_For_Mac_OS_X_Looks_Exactly_Like_Safari

Comment 5

[Jesse Ruderman]

The reload arrow seems to be pointing outside of the circle, and looks unfortunately similar a power button.

Comment 6

[Stephen Horlander [:shorlander]]

Attachment: Full Toolbar Icons 1

Updated screenshot with new toolbar icons and some small tweaks/refinements like APNG throbber, star icons, bookmark pressed state, etc.

Comment 7

[Kyle]

Come on now. I realize this is a mock-up, but it looks as if you are just trying to imitate Safari. Safari does not have the best looking interface, and (from a graphic designers point of view) it wouldn't be too difficult to out-design Apple.

Personally, I think these 2 browsers have a better looking UI:
Camino - http://caminobrowser.org/
Omniweb - http://www.omnigroup.com/applications/omniweb/

Again, use these as a source of inspiration, but don't blatantly rip off their design too. I know there is enough talent out there to come out with something better that still looks visually integrated into OS X.

Here is an example of colorful icons that look visually integrated into OS X. I think they are rather sleek too:
http://www.mattballdesign.com/portfolio/icons/devicons/devicons.jpg

You can view Matt's full portfolio here: http://www.mattballdesign.com/portfolio/

I'm not trying to be too harsh or mean, I'm just trying to show you that there are options available for creating something that is unique that still maintains the OS X feel. I know there is plenty of talent and creativity out there, so use it!

Comment 8

[Michael Ventnor]

In the latest mockup the back and forward buttons are together. In the
customize dialog you can move them separately, how would you deal with the case
where they are put in different positions?

Comment 9

[Jesse Ruderman]

Leopard's toolbar background is much darker than Tiger's, so copying Camino's current look probably wouldn't work well.

Comment 10

[philippe (part-time)]

(In reply to comment #9)
> Leopard's toolbar background is much darker than Tiger's, so copying Camino's
> current look probably wouldn't work well.
> 
We were actually having that discussion in the camino forums. Quite a few Camino users seem to prefer monochrome or less colourful icons on 10.4, but some are thinking that for the dark (drab ?) look of Leopard, some stronger, more colourful icons may be better.

(In reply to comment #6)
> Created an attachment (id=282647) [details]
> Full Toolbar Icons 1
> 
How does that work out on the 10.4 Tiger lighter background colour ?

Comment 11

[Alex Faaborg [:faaborg] (Firefox UX)]

>How does that work out on the 10.4 Tiger lighter background colour ?

I am pretty sure we are going to have the same window appearance on 10.4 and 10.5, similar to iTunes.

Comment 12

[Dão Gottwald [:dao]]

The apng throbber that (I think) Justin Dolske put together didn't work well on different backgrounds. It would be nice if varying rgb values could be used rather than varying alpha values, so that it'll work on black as well as on white.

Comment 13

[Rob Campbell [:rc] (:robcee)]

From Stephen's latest screen shot there are some vertical offset issues with some of the buttons. The reload button looks like it's a pixel higher than it should be (maybe an illusion) and the new tab and new window buttons the '+' isn't in a consistent spot.

Safari look-alike-aside, I like the clean look and darker "unified" toolbars.

Dão: That would be nice, but in any case, the new throbber's a big improvement over what we had before.

Comment 14

[Jurriaan Mous]

Attachment: Evolution on first mockup

My concept on the toolbar. With some influences of some of the fullscreen interfaces like frontrow and time machine and fits the recent aluminium iMacs.

I think this is more a direction/evolution the future OSX will take. Also some iphone blue tint in selection and more color in the buttons for better intuitive browsing. We need to look better than Safari. :) Text has a bit glow instead of shadow. I also realigned images in buttons for better look. Not as clean edited as should be.

Comment 15

[Erin 'Folletto' Casali]

(In reply to comment #14)
> My concept on the toolbar. With some influences of some of the fullscreen
> interfaces like frontrow and time machine and fits the recent aluminium iMacs.

I like it, but consider that black has a specific meaning: if the interface isn't black based, it's usually related to floating palettes, not toolbars.
Also, it brings in some inconsistencies: the selected tab is black, but the deselected ones are gray, like other UI elements. The perception of these elements could be confusing.

Also, be very careful to 'attach' the tab on top, instead than on bottom (bookmarks-side vs page-side). Even if Safari does it, semantically it's a bit confusing (the tab is a page, not a bookmark).

Maybe, we could take the first mockup of the tabs and make the bookmarks bar whiter? :)

> I think this is more a direction/evolution the future OSX will take. Also some
> iphone blue tint in selection and more color in the buttons for better
> intuitive browsing. We need to look better than Safari. :) Text has a bit glow
> instead of shadow. I also realigned images in buttons for better look. Not as
> clean edited as should be.

Be careful also with glow and gradients: readability is very important. :)

While, I agree on a bit of azure/blue 'tech' glow on selected/enabled buttons. ;)

While Fx shouln't copy Safari, note that back/next arrows on Safari are just triangles, not full arrows. ;)

Comment 16

[Ryan A. C.]

I'm not a fan of the tabs attaching to the top at all. I never quite understood why apple did it with Safari for any reason other than looks, especially when the rest of the OS uses a proper tab metaphor.

The tabs should be attached to the page, as a matter of human interaction and the 'binder separation tab' metaphor it enforces the relationship between the tab and the page.

Comment 17

[Stephen Horlander [:shorlander]]

(In reply to comment #16)
> I'm not a fan of the tabs attaching to the top at all. I never quite understood
> why apple did it with Safari for any reason other than looks, especially when
> the rest of the OS uses a proper tab metaphor.
> 
> The tabs should be attached to the page, as a matter of human interaction and
> the 'binder separation tab' metaphor it enforces the relationship between the
> tab and the page.
> 

This is a common, but not entirely accurate, comment. While seemingly unintuitive at first glance having the tabs attached to the toolbar is actually quite logical.

The tab itself is not in fact tied to a webpage. The webpage is variable. The tab is controlled by the toolbar interface. The actual viewport of the tab is controlled internally by the webpage. Of course it doesn't make as much sense tied to the bookmarks bar. Although that might be debatable in Safari because the bookmark bar also controls the bookmarks manager.

http://www.noved.org/~stephen/theme_screenshots/toolbar_tied_to_tabs.png

Comment 18

[Ray Ryan]

When Mac users complain about better integration with the OS, chrome is the least of it. When people talk about "look and feel", look is only 10% of what matters. Feel--correct behavior--is everything, is harder, and is what cross platform developers tend to ignore. Every moment spent sweating over layout instead of using the native services better is a moment  wasted.

I'd be perfectly happy with the current chrome if you:

• used cocoa widgets, especially for text editing.

• Follow the standard keybindings pathologically. 

• Fix your window zoom behavior--this isn't Windows or Linux,  we don't want you to take over the screen, rather to optimize size based on content

• Fix your multiple-monitor behavior. When you drag a FireFox window from a large screen to a small one, only bad things happen.

• Fix your tendency to snap a window to the wrong place when it's being dragged--often when I drag window b, you snap it back to the origin of window a when I let go.

Half of these problems wouldn't even exist if you'd gone down the Cocoa road instead of Carbon nine years ago.

Comment 19

[Erin 'Folletto' Casali]

(In reply to comment #17)
> This is a common, but not entirely accurate, comment. While seemingly
> unintuitive at first glance having the tabs attached to the toolbar is actually
> quite logical.
> 
> The tab itself is not in fact tied to a webpage. The webpage is variable. The
> tab is controlled by the toolbar interface. The actual viewport of the tab is
> controlled internally by the webpage.

I don't want to start a debate here, however I think from the perception point of view that what a tab-switch operation changes is the page, not the top controls: they are/seem fixed.
Also, it's common to have the tabs "over" the content that the tabs are switching (also... the tab is variable, as it is the page).

However, as said, I don't feel good to start a debate here. In fact I think that *readability* and *consistency* is the most important thing: above or below doesn't change for me as far as those points are addressed well. :)
It was just an usability and perception consideration that should be weighted, not a must-do law. ;)


(In reply to comment #18)
> When Mac users complain about better integration with the OS, chrome is the
> least of it. When people talk about "look and feel", look is only 10% of what
> matters. Feel--correct behavior--is everything, [...]
> Half of these problems wouldn't even exist if you'd gone down the Cocoa road
> instead of Carbon nine years ago.

While I could or could not agree with you, I don't think this is the right place for those comments. This "Bug" is about a new Theme and nothing else. ;)

Back to topic and mockups! :D

Comment 20

[Colin Barrett [:cbarrett]]

(In reply to comment #18)
> When Mac users complain about better integration with the OS, chrome is the
> least of it. When people talk about "look and feel", look is only 10% of what
> matters. Feel--correct behavior--is everything, is harder, and is what cross
> platform developers tend to ignore. Every moment spent sweating over layout
> instead of using the native services better is a moment  wasted.

Please try to remain on topic, Ryan. We're discussing the new theme here. We all understand those issues are important, and some of them have even been fixed already for Firefox 3.

We're all on the same team here, folks.

And thanks, David, for making the same point :)  It's going to be tough to keep this bug on topic, but I think we can do it. Give gentle reminders and be polite :)

Comment 21

[Colin Barrett [:cbarrett]]

Here's some feedback I gave originally to Steven and Kevin:

I for one do not like the Safari style toolbar icons. I think having brightly colored toolbar icons can work on Leopard. Coda is an excellent example of this -- Cabel said at C4[1] put a lot of work into the interface to make sure it looks good on Leopard, and the icons are a real boon there.

I also do not like the find field. I think it looks really really busy. First off, we don't need a clickable button on the right. Enter to submit works fine. Secondly, I think it would look much less odd if the field just had a magnifying glass like iTunes or Mail (with a little dropdown arrow to select the search site). In the actual text of the field, would be the favicon for the site and the name in grey text. Clicking on in the field would make both the favicon and the text go away.

Comment 22

[Kevin Gerich]

(In reply to comment #21)
> I also do not like the find field. I think it looks really really busy. First
> off, we don't need a clickable button on the right. Enter to submit works fine.

I agree it would be ideal to just drop the button. Safari and the iTunes music store use the enter-to-submit behavior on their search fields. 

> Secondly, I think it would look much less odd if the field just had a
> magnifying glass like iTunes or Mail (with a little dropdown arrow to select
> the search site). In the actual text of the field, would be the favicon for the
> site and the name in grey text. Clicking on in the field would make both the
> favicon and the text go away.

I like the idea of adding a magnifying glass icon, but in addition to the favicon? That sounds like it would be confusing to folks who are used to clicking on the favicon to open the search engine menu. It would also make the widget even more busy. Perhaps we should get rid of the search favicon entirely    - the text inside the field reminds users which engine they've selected.  

Comment 23

[Stephen Horlander [:shorlander]]

(In reply to comment #21)
> Here's some feedback I gave originally to Steven and Kevin:
> 
> I for one do not like the Safari style toolbar icons. I think having brightly
> colored toolbar icons can work on Leopard. Coda is an excellent example of this
> -- Cabel said at C4[1] put a lot of work into the interface to make sure it
> looks good on Leopard, and the icons are a real boon there.

Personally I am not all about the glyph style icons either. I don't dislike them, and I can see what they bring to an interface, but color is often preferred for various reasons including aesthetics. Although sometimes the glyph style icons are better suited.

However I would have to disagree that current apps like Coda look good on Leopard's dark toolbar background. On the light grey Aqua Unified windows they look great. They are vibrant, distinctive and they flow. They also do this without getting in the way.

On the dark background they just look... foreign. Apple, with this new toolbar style, has someone managed to make these types of icons get lost in the darkness of it while simultaneously sticking out and appearing out of place. Some of this is probably relative. I mean if I had never seen an aqua style Coda maybe I wouldn't mind the new look. 

That isn't to say that I don't think you can create colored icons that would work. I just don't think current examples do/will. I would say look at Aperture for colored icons that work well in dark settings, but Aperture is somewhere between current Aqua and Leopard metal in terms of darkness.

> I also do not like the find field. I think it looks really really busy. First
> off, we don't need a clickable button on the right. Enter to submit works fine.
> Secondly, I think it would look much less odd if the field just had a
> magnifying glass like iTunes or Mail (with a little dropdown arrow to select
> the search site). In the actual text of the field, would be the favicon for the
> site and the name in grey text. Clicking on in the field would make both the
> favicon and the text go away.

Pretty much what Kevin said.

Also keep in mind that I am largely trying to work within the confines of what FF3 presently looks like where possible. It's not always ideal to count on securing outside-of-theme UI changes if we don't have to. 

One plus to the current implementation is that it does serve as a point of differentiation. :)

Comment 24

[Colin Barrett [:cbarrett]]

(In reply to comment #23)
> Personally I am not all about the glyph style icons either. I don't dislike
> them, and I can see what they bring to an interface, but color is often
> preferred for various reasons including aesthetics. Although sometimes the
> glyph style icons are better suited.

I think we can find a solution.

> However I would have to disagree that current apps like Coda look good on
> Leopard's dark toolbar background. On the light grey Aqua Unified windows they
> look great. They are vibrant, distinctive and they flow. They also do this
> without getting in the way.
> 
> On the dark background they just look... foreign. Apple, with this new toolbar
> style, has someone managed to make these types of icons get lost in the
> darkness of it while simultaneously sticking out and appearing out of place.
> Some of this is probably relative. I mean if I had never seen an aqua style
> Coda maybe I wouldn't mind the new look. 

I really disagree here. I would highly suggest trying Leopard out for a while (Maybe someone can donate a seed key to you). It takes a bit to get used to.

> Also keep in mind that I am largely trying to work within the confines of what
> FF3 presently looks like where possible. It's not always ideal to count on
> securing outside-of-theme UI changes if we don't have to. 
> 
> One plus to the current implementation is that it does serve as a point of
> differentiation. :)

Yes, but different does not imply good ;)

Comment 25

[Stephen Horlander [:shorlander]]

Attachment: Modified Search

(In reply to comment #24)
> Yes, but different does not imply good ;)

Really? I thought different, much like bigger and louder, was always better :)

If we could remove the right side search button then I would rather like it. It has a nice flow with the location bar.

Comment 26

[Marcia Knous [:marcia]]

I echo Colin's sentiments in Comment 21. I don't like the icons as presented and would prefer something with a bit more pop.

Comment 27

[Alex Faaborg [:faaborg] (Firefox UX)]

I've set up a wiki page for designers to post their mockups of various mac theme ideas:

http://wiki.mozilla.org/Firefox3/Theme/MacOSX

When looking through a bunch of screen shots wiki pages are a little nicer because you can see all of them without having to navigate to different attachments, and I think our wiki is a little more accessible than bugzilla to designers.

Comment 28

[philippe (part-time)]

One nitpick I have with the current (FX 2) theme: when a site broadcast OpenSearch (like Bugzilla), the little arrow in the search box, next to the favicon glows (blueish colour). The problem: it is not or barely visible. Granted, it is a little better than on Fx windoze, but not much. 
IE 7 uses an orange background for this. Camino, when it implements OpenSearch support, will almost certainly use a clearly visible orange background (behind the magnifying glass) as well - mock-ups in bug 358798.
Hopefully something like this can be done for Fx 3.

Comment 29

[Alex Faaborg [:faaborg] (Firefox UX)]

(in reply to comment #23)

>Also keep in mind that I am largely trying to work within the confines of what
>FF3 presently looks like where possible. It's not always ideal to count on
>securing outside-of-theme UI changes if we don't have to. 

I'll try to regularly comment in this bug with possible changes to the Firefox
3 UI, because the UI can obviously change the theme, and vice versa.

One thing in particular that we know is landing is the Identity (SSL, EV)
button on the left of the location bar (bug #395248).  Here is some possible
visual styling on OS X: https://bugzilla.mozilla.org/attachment.cgi?id=280429

In terms of the search bar: I agree that putting the search icon on the wrong
side creates an external consistency issue, but I think it also balances well
with the combination of the favicon button->text field->star in the location
bar.



Here are some changes that aren't final yet, but might happen:

The current right side of the location bar (lock, rss, drop down arrow, star,
go) which some people on the UX team have deemed our "lucky charms" (we need to
add a Purple Horseshoe), will hopefully end up being just the star.  Here is
what would happen to the other controls:

-RSS: moved to the favicon / identity menu.  Not that many people use the RSS
button, and even those that do only hit it once per feed (so maybe 20-30
times), so there isn't much reason to place it in primary UI.  It is useful to
glance up and see if a feed is available, but I think even this action is rare
enough to warrant having the user click once to display the favicon menu if
they are curious.  Here is a mockup of the favicon menu:
http://people.mozilla.com/~madhava/files/favicon/mockups_2007-07-27/fullmenu_option1.png


-Lock: moved to the favicon / identity menu.  Johnathan who is in charge of our
security UI has a presentation about the change here:
http://test.johnath.com/dropzone/Beyond%20the%20Padlock%20v7.pdf

-Drop down arrow: appears on mouse hover on the location bar

-Go Button: an arrow glyph inside the location bar (similar to the star)
replaces the star when the user starts editing the field

For the places UI (bug #393509), I think we should seriously consider a HUD
style panel with a small half diamond arrow point up to the star.  I think we
should think about doing this for the favicon as well, I'll try to get some
mockups posted to the place bugs.

Comment 30

[Erin 'Folletto' Casali]

(In reply to comment #29)
> One thing in particular that we know is landing is the Identity (SSL, EV)
> button on the left of the location bar (bug #395248).  Here is some possible
> visual styling on OS X: https://bugzilla.mozilla.org/attachment.cgi?id=280429

Roger that. :)
But... doesn't that UI risk to be too long, covering the whole or most of the address bar if the url/name is too long?


> The current right side of the location bar (lock, rss, drop down arrow, star,
> go) which some people on the UX team have deemed our "lucky charms" (we need to
> add a Purple Horseshoe), will hopefully end up being just the star.  Here is
> what would happen to the other controls:
> 
> -RSS: moved to the favicon / identity menu. [...] 
> -Lock: moved to the favicon / identity menu. 

I don't agree with those possibilities... both the RSS and the Lock are a clear message to the user, and about RSS it contributes to the diffusion, while the lock increases security perception (habits?).

Where the discussione about this is being held? Of course, if I could join... ;)


> -Drop down arrow: appears on mouse hover on the location bar  
> -Go Button: an arrow glyph inside the location bar (similar to the star)
> replaces the star when the user starts editing the field
 
Those seems nice, also the hovering that usually I don't like in those situations, in the end I don't have ever seen anyone using explicitly that dropdown. :P

Comment 31

[Erin 'Folletto' Casali]

Meanwhile, I've added a few images to the wiki, trying to get out the lighter glossy bookmarks bar I was imagining and also the new UI consideration added by Alex (with a little proposal for the icons). ;)
http://wiki.mozilla.org/Firefox3/Theme/MacOSX

Comment 32

[Dão Gottwald [:dao]]

(In reply to comment #29)
> One thing in particular that we know is landing is the Identity (SSL, EV)
> button on the left of the location bar (bug #395248).  Here is some possible
> visual styling on OS X: https://bugzilla.mozilla.org/attachment.cgi?id=280429

Please don't set this UI in stone until bug 397594 is resolved. The only proposed solution so far, "the identity UI should shrink back to just a favicon button when you edit the location", will not work. It would shift the entire address, which is certainly not helpful if you want to edit it.

Comment 33

[Jurriaan Mous]

I added a new proposal to the wiki page with some macbook/new keyboard inspired buttons based on Folletto's design.

http://wiki.mozilla.org/Firefox3/Theme/MacOSX

Comment 34

[Jurriaan Mous]

Since OSX is all about removing everything but the essential, shouldn't we combine the stop and reload into one button? I do it always manual with an extension but why not default? (safari also does it) And maybe more controversial: Remove the home button? And maybe add a standard home link/icon to the bookmarks bar? 

Just back&forward and the stop/reload button on the main toolbar. And very maybe a + icon to add bookmarks. (just as Safari)

And give the users the option of returning them with the already present customize option. It is maybe also easier for Safari converts :) (as the buttons were historically left for IE6 converts on Windows.)

Comment 35

[Jurriaan Mous]

Tested it out with some other changes in the latest addition to the wiki:

http://wiki.mozilla.org/Firefox3/Theme/MacOSX

Comment 36

[Erin 'Folletto' Casali]

(In reply to comment #34)
> Since OSX is all about removing everything but the essential, shouldn't we
> combine the stop and reload into one button? I do it always manual with an
> extension but why not default? (safari also does it) And maybe more
> controversial: Remove the home button? And maybe add a standard home link/icon
> to the bookmarks bar? 

1. Combined Reload/Stop I think has been discussed since a long time. Excluding the fact that it will need some programming, it's an usability problem: you're combining in one UI element two opposite functions. Also, it's not uncommon to "hammer" the Stop button in order to get some load stop: if it's combined, you'll risk to keep it stopping and reloading.
I think it should be left as an extension.

2. For the home button, as easy as it could be removed or added, I don't think is an issue and from my point of view I think that Firefox should be 'equal' il the default functionalities on all the platform. :) - While I agree that moving it to the bookmarks bar will be better: in fact it's just 'history' if we keep a "home" page, while it's just another 'special' bookmark.

3. What I'd really like to have will be the Safari load indicator in the Location bar, like what does the Fission plugin on Fx2.0. It's cleaner, more visible and really unobtrusive. :) But I think that this is a change that will impact many other codes. I hope that someone could answer me about this point. :)


(In reply to comment #35)
> Tested it out with some other changes in the latest addition to the wiki:
> 
> http://wiki.mozilla.org/Firefox3/Theme/MacOSX

I think that some color on the buttons is great. Maybe we should work on finding a 'distinctive-while-still-OSX-look' ok them. :)
A combination of that plus an improved locationbar, will make Firefox "unique".

If it's possible, I love also moving the home button on the bookmark bar, even if as I just said I don't like the combo button solution reload/close. :) 

Comment 37

[Jurriaan Mous]

Stop/reload extension works for me but it is possible that this change can hold some confusion. Is this tested somewhere or only logical argumentation? Because Apple comes away with combining it in Safari. And hammering is illogical when using the plugin, since Firefox stops immediately. Ah well I can live with installing an extension for myself :)

Load indicator in location bar would indeed be nice. Because it would almost obsolete the status bar.

The colors are inspired by last/current gen iPod Nanos. Not as much used in OSX but those are Apple approved :) I think it gives a more distinctive look than using more normal bright colors. We also need some differentiation because Mr Jobs targeted Firefox for annihilation last WWDC. And some controversial cool colors is maybe using Apples own weapons against them :P This time converting some of their hardware design successes to software. Apple is staying conservative with Safari and with Leopard almost out of the door they can't update Safari look for 2 years.

You love or hate it and with firefox you can reskin it to more neutral with the many safari look a like skins :)

Comment 38

[Jurriaan Mous]

Hmm, looking at the colors on an other screen than my iMac it looks not as good as should... Well then the purple/pink looks really out of place. Color suggestions?

Is this general direction ok with the glass bookmarks and macbook/keyboard buttons or should other roads be discovered? How is the direction of the theme decided?

Is black glass better than white? Mac friends suggest a preference option for both (some like white/some black), is that possible? Or maybe charge for the black theme :P

Comment 39

[Chris Blore]

(In reply to comment #38)
> Is black glass better than white? Mac friends suggest a preference option for
> both (some like white/some black), is that possible? Or maybe charge for the
> black theme :P

At the risk of turning this into a debate rather than a bug, it seems to me that black glass is used mostly for pro-apps eg. Aperture, or at least "creative apps" such a iPhoto. I'm not sure that I'd class Firefox in the same category.

Comment 40

[Erin 'Folletto' Casali]

(In reply to comment #38)
> Hmm, looking at the colors on an other screen than my iMac it looks not as good
> as should... Well then the purple/pink looks really out of place. Color
> suggestions?

If we need colors, I'll follow the road of cosinstency with Camino. Green/Red/Blue. :)


> Is this general direction ok with the glass bookmarks and macbook/keyboard
> buttons or should other roads be discovered? How is the direction of the theme
> decided?

I think that at this time we should try a lot, keeping 'integration & distinction' as our first objective. :)



(In reply to comment #39)
> At the risk of turning this into a debate rather than a bug, it seems to me
> that black glass is used mostly for pro-apps eg. Aperture, or at least
> "creative apps" such a iPhoto. I'm not sure that I'd class Firefox in the same
> category.

I agree. Also, black requires FULL black applications (or, dark styled) and I don't think it will fit well on a white-based UI like Mac OS X, since Firefox isn't a pro application and will be opened on every desktop with many other applications. Also, please remember that our eyes require a little time to adapt on inverted colors, so I don't think that black will be a good usability choice, at least for the default theme. ;)

Comment 41

[Jurriaan Mous]

Well, then black will be a separate download. :P 
(Although I don't think the consumer/user is aware of black=pro. Wouldn't they prefer something more expensive looking :) And since iTunes coverflow/Garageband/Front Row are also black.)

The red is back as stop button to complete green/red/blue. Although I am a proponent of combining stop and reload.

The + has been moved to the bookmark bar just like the home previously. Although it has now a double presence with the invisible star on location bar. Both or one of both? Drop the +?

Less rounded corners this time to make the location bar more of a whole and more space efficient.

And a minimized pill mode design.

http://wiki.mozilla.org/Firefox3/Theme/MacOSX

Comment 42

[Erin 'Folletto' Casali]

(In reply to comment #41)
> Well, then black will be a separate download. :P 
> (Although I don't think the consumer/user is aware of black=pro. Wouldn't they
> prefer something more expensive looking :) And since iTunes
> coverflow/Garageband/Front Row are also black.)

Sure but: Coverflow is a "hole" in the application, while Front Row is completely black. In one case it's a specific reason, in the other it doesn't have the same integration requirements that in my opinion Fx has. ;)
However, of course, it's debatable. :)

> The + has been moved to the bookmark bar just like the home previously.
> Although it has now a double presence with the invisible star on location bar.
> Both or one of both? Drop the +?

I find your "+" solution interesting, but still I think that the star should be the only one way to do that. :) It's also in the best position possible to do its work. :)
I'll keep just the star, with some work on its two statuses. :)


> Less rounded corners this time to make the location bar more of a whole and
> more space efficient.
> And a minimized pill mode design.

Uhm. Seeing your mocks, I think I will choose a road without rounded corners at all (exlcuding the search box, of course). I think they're simply better and more efficient.

I'll throw in a consideration (regarding rounded location bar): the square solution I think fits well since it matches better the flat buttons on its side.

You've raised an issue: I don't know if a sizing control exists between location bar and search box. I'm saying this because in the middle of those I put reload and stop, like Explorer does... and I can't do that on Safari, that has the handle. I think that we should keep the flexibility to mirror the IE7 button layout, but that could be just me. :)

In the end, this is the best solutions so far. I'll try to experiment a bit. :)

Comment 43

[Jurriaan Mous]

Ah well lets go for the white version for now :) If Mozilla gets overrun with requests for a black version we could always reconsider it for firefox 4 :P

The star will remain as only one in next update then for bookmarking

Indeed, I think I will also remove the most left rounded side. I will leave the left search flat for better space for favicon. Right of search will remain rounded.

Hmmm, the sizing control... Maybe it should attach to the search and keep the possibility of adding buttons to the left of it opening both options?

Added a new inline find and bottom of window proposal.

http://wiki.mozilla.org/Firefox3/Theme/MacOSX

Comment 44

[Erin 'Folletto' Casali]

(In reply to comment #43)
> Hmmm, the sizing control... Maybe it should attach to the search and keep the
> possibility of adding buttons to the left of it opening both options?

It seems a good solution to me. :)

>  Added a new inline find and bottom of window proposal.

Very nice. I think that it could be included as you designed it. ;)

~

I've added some other tabs-bookmarks-toolbar integration mockups. I'm not satisfied by the tabs, but I think that unifying the rest should be ok. :)
Comments? :)

http://wiki.mozilla.org/Firefox3/Theme/MacOSX

Comment 45

[Robert Accettura [:raccettura]]

May I propose that Firefox on Mac OS X ship with an extra toolbar button?  Stop/Reload.  Just give users a choice.  There's a clear split.  There's no real "overhead" in providing it.

The latest evolution looks rather good.  I'm not sure about the black search bar though.  Maybe it's just me, but it looks out of place.  Especially compared with Safari's purplish-blue bar, and Coda's use of brushed metal for similar functionality.  Both of them do it on the top, though I don't think placement is as important as style in this case.

On a sidenote, perhaps bug 251198 has slight relevance here, as many consider it part of theming (though it's technically not).

Comment 46

[Samuel Sidler (old account; do not CC)]

(In reply to comment #45)
> May I propose that Firefox on Mac OS X ship with an extra toolbar button? 
> Stop/Reload.  Just give users a choice.  There's a clear split.  There's no
> real "overhead" in providing it.

No, but you can file a new bug for it (after searching, of course; bug 343396 might be what you're looking for). This bug is about a new theme for Mac OS X not about shipping new toolbar buttons.

That being said, it'd make sense to move most of the discussion to the wiki page or to a new topic in the newsgroups (m.d.themes or m.d.a.firefox probably). Bugzilla isn't the best for tracking discussions like this.

Comment 47

[Jurriaan Mous]

Added some new inline find options to the wiki. (blue/white glass/brushed metal) Top could maybe work with the blue but for bottom option I think the contrast rich black is necessary and adds a bit of coolness by giving inline search an advanced pro feel. ;) :P

Also some small changes to the top toolbar while busy.

http://wiki.mozilla.org/Firefox3/Theme/MacOSX

I think animation in the default skin is really necessary. Really when comparing it to 'competitor' Safari. 
A slide-up down of the inline find. (with easing) A pop/grow of the location bar icons for more attention. Poping words when search. Fading of buttons on toolbar when disabled. Very slight glowing/pulsing/breathing of toolbar buttons when hovering over them. Slot machine search engine selection when setting one. Very quick fade in of current tab on bar selection and fade to bg when deselected. Slide/fade/pop in of identity button. Browsing should have more subtle fun.

Of course with OSX subtleness but with Core Animation coming it becomes more important. What is possible now?

Comment 48

[Wayne Woods]

Not wanting this bug to snowball into a 50-page debate, I started adding my thoughts to the Discussion page attached to that Wiki mockups page. If it's not the best place to discuss it, please let us know where we should post.

Comment 49

[Jurriaan Mous]

Added some experiments like bottom connected tabs, standard RSS icon, favicons on toolbar, active reload button to wiki. 

Also earlier a more generic look of the skin without identity thing.

http://wiki.mozilla.org/Firefox3/Theme/MacOSX

Comment 50

[Aronnax]

Hi, 
first of all many, many thanks to Colin Barrett.  Without his hard work over some months to find and build a Unified Toolbar solution would it be impossible to create a good theme which fit well in Mac 10.4 and 10.5 and least of all would fit well in both systems. Many, many thanks ;-) 

A picture from a test version of one of my next GrApple themes: 
http://www.takebacktheweb.org/themes/stuff/GrApple_3.0_test.png
It is not a suggestion for the default theme, but it goes in the same direction and is therefore maybe helpful for a comparison - and by the way, it will replace GrApple (Eos),  the GrApple (Eos Pro) theme with the same design but different tabs (well known) has much higher download numbers (more than twice as much)  http://www.takebacktheweb.org/

On the picture: 
1. It is a screenshot with the current (unfinished)  theme - created together with a special Firefox version, which has already the Unified Toolbar patch 
The limitation not to add a gradient on the title-bar enforce a compromise - the top is a little bit darker than usual for a (Leopard) Unified Toolbar design and at the bottom is it more brightly as usual 
https://bugzilla.mozilla.org/show_bug.cgi?id=303110

2. the final 3.0 version will have the new Star Button inside the location bar - makes it then as well possible to create a cleaner location bar  

3. with the missing 3.0 features on the sidebar - to compare http://tinyurl.com/2ojfvr

4. to show the search-bar feature  - the search-go button (the orange button) appears only when it is necessary 
and as well the tab-scroll feature

5. Places - the current state

6. Places - with the missing stuff - to compare http://tinyurl.com/3b44jd


Cheers 

Comment 51

[Wayne Woods]

Should this bug be marked dependant on bug 303110? It seems a lot is going on there that should be related to this, but there's no cross-reference whatsoever...

Comment 52

[x00n]

i have somo proposal:

1 : The Bookmarks (and History) sidebar may open into a external side panel (like standard in cocoa), this add more coherence with osx gui.
2 : The current interface does not support the little down arrow near the back arrow that open the last 10 visited pages.
3 : History button is much used by users why don't integrate it in the default interface?

Comment 53

[Markus S.]

Just use an updated Pinstripe. Thank you.

Comment 54

[Erin 'Folletto' Casali]

(In reply to comment #52)
> i have somo proposal:
> 
> 1 : The Bookmarks (and History) sidebar may open into a external side panel
> (like standard in cocoa), this add more coherence with osx gui.

The OSX UI is drifting away from that solution, that was criticized since day 1. I don't think it will be a good choice, also because I don't think that the engine could support it. :)

Comment 55

[Jurriaan Mous]

(In reply to comment #52)
> i have somo proposal:
> 
> 1 : The Bookmarks (and History) sidebar may open into a external side panel
> (like standard in cocoa), this add more coherence with osx gui.


Indeed the latest Leopard builds have the last drawers removed from many applications.

For example preview:
http://www.appleinsider.com/articles/07/10/02/road_to_mac_os_x_leopard_an_extensive_look_at_preview_3_0.html
(see window layout)

Comment 56

[x00n]

Well i just can say that ,Davide Casali and Jurriaan Mous you are totally right for the side bar.

Maibe the solution for the history button can be a button(or two) in the side bar that switch Bookmarks and History, like the buttons in the side bar of the new leopard preview app.

Comment 57

[Kevin Gerich]

Attachment: browser and toolkit theme changes, diff against trunk

Comment 58

[Kevin Gerich]

Attachment: Modified and added images

Comment 59

[Kevin Gerich]

Comment on attachment 283988 [details] [diff] [review]
browser and toolkit theme changes, diff against trunk

this patch is designed to look best with the unified toolbar patch from bug 303110

Comment 60

[Wayne Woods]

Any screenshots, Kevin?

Also, are these your proposed ideas to add to what's already being bandied around? Or is this the way it's going to be?

Comment 61

[Kevin Gerich]

Attachment: Screenshot of work in progress

Thanks for reminding me to post a screenshot Wayne.

This patch is an implementation of Stephen's mockups .. It looks more or less like the other mockups, with some differences in the tab design.

Comment 62

[Erin 'Folletto' Casali]

I don't know if this has been already discussed, but on Mac shouldn't the close button be placed on the left of the tab, right before the tab favicon? :)

Comment 63

[Dão Gottwald [:dao]]

Comment on attachment 283988 [details] [diff] [review]
browser and toolkit theme changes, diff against trunk

>Index: browser/base/content/tabbrowser.xml
...
>       <xul:hbox flex="1" class="tab-image-middle" align="center" xbl:inherits="selected">
>         <xul:stack class="tab-icon">
>           <xul:image xbl:inherits="validate,src=image" class="tab-icon-image"/>
>           <xul:image class="tab-extra-status"/>
>         </xul:stack>
>-        <xul:label flex="1" xbl:inherits="value=label,crop,accesskey" crop="right" class="tab-text"/>
>+        <xul:stack class="tab-text-stack" flex="1">
>+          <xul:label flex="1" xbl:inherits="value=label,crop,accesskey" crop="right" class="tab-text-shadow"/>
>+          <xul:label flex="1" xbl:inherits="value=label,crop,accesskey" crop="right" class="tab-text"/>
>+        </xul:stack>

For performance reasons, please don't do such changes within the cross-platform bindings.

Comment 64

[Hank Mills]

(In reply to comment #62)
> I don't know if this has been already discussed, but on Mac shouldn't the close
> button be placed on the left of the tab, right before the tab favicon? :)
> 

For Firefox 2 it was discussed quite a bit on bug 349108. I'll restate here what I wrote there, I think it looks best, and is most "mac like" with the close button on the left and the favicon attached to the tab title, rather than permanently stuck to an edge.

Comment 65

[Erin 'Folletto' Casali]

(In reply to comment #64)
> For Firefox 2 it was discussed quite a bit on bug 349108. I'll restate here
> what I wrote there, I think it looks best, and is most "mac like" with the
> close button on the left and the favicon attached to the tab title, rather than
> permanently stuck to an edge.

I agree for the sequence close, favicon, title too, while I prefer the favicon attached to the close button. ;)

Comment 66

[Alex Faaborg [:faaborg] (Firefox UX)]

Last I heard the plan was to swap the favicon on the far left for the close button on mouse hover on the tab.

Comment 67

[philippe (part-time)]

(In reply to comment #66)
> Last I heard the plan was to swap the favicon on the far left for the close
> button on mouse hover on the tab.
>
That has the sounds of mystery-meat navigation...

The close button is a window control where as the favicon is a file-proxy.
In Fx 2.0.x, the favicon does nothing except giving some visual clue. In Camino, the favicon is a real file-proxy that you can drag around, just as you would do things by command-clicking or dragging the file-icon in the title bar of say TextEdit.app.

Comment 68

[Wayne Woods]

(In reply to comment #67)
> (In reply to comment #66)
> > Last I heard the plan was to swap the favicon on the far left for the close
> > button on mouse hover on the tab.
> >
> That has the sounds of mystery-meat navigation...
> 
> The close button is a window control where as the favicon is a file-proxy.
> In Fx 2.0.x, the favicon does nothing except giving some visual clue. In
> Camino, the favicon is a real file-proxy that you can drag around, just as you
> would do things by command-clicking or dragging the file-icon in the title bar
> of say TextEdit.app.


Same in the Firefox trunk. It's something I don't think we should be removing. Plus in practice it's not so neat in Adium when you accidentally close a small tab instead of selecting it when the icon turns into a close button at the last second.

Comment 69

[Kevin Gerich]

(In reply to comment #67)
> (In reply to comment #66)
> > Last I heard the plan was to swap the favicon on the far left for the close
> > button on mouse hover on the tab.
> >
> That has the sounds of mystery-meat navigation...

I totally agree. I was thinking of something more along these lines...

http://kmgerich.com/archive/temp/tab-mockup1.png

Comment 70

[philippe (part-time)]

(In reply to comment #69)

> http://kmgerich.com/archive/temp/tab-mockup1.png
> 
That is already much better (iCab handles it the same way, btw).
I think that quite old versions of Camino did that as well (but now settled left aligned text in the tabs).

Comment 71

[Wayne Woods]

Thanks Kevin, for your screenshots. It's looking very professional. A bit of feedback, if I may, from obviously a personal viewpoint:
- The shading and backgrounds for the windows, toolbars and buttons look fantastic
- The "round within round" shape of the search bar, while obviously designed in a professional manner, somehow "feels" strange to me. I can't explain why, exactly, but it pulls my gaze every time I go back to that screenshot, in a way that it shouldn't. I assume it's the oddness of having concentric shapes. Have you considered something based on the "location and search bar as matching halves" approach which JurMous introduces about half way down the wiki page?
- I really still think coloured toolbar icons are the way to go. I think they *can* look very Mac-like, are more visually practical, and I also wouldn't underrate their importance for us looking distinguished from (and better than) the Safari UI. The wiki page shows they can work (though those are obviously experimental and unpolished). Perhaps a more "anodized aluminium" colouring would work though?
- I'm afraid I still can't get used to the upside-down tabs. The active tab, where it completely merges with the bookmarks bar, just hits as plain wrong and illogical, regardless of what comment 17 tries to justify. Though maybe that's as much to do with the switch from gradient to solid colour as as it is to do with logic. But if Safari didn't do it, I think a lot more people would be going "huh?"

Comment 72

[Erin 'Folletto' Casali]

(In reply to comment #69)
> I totally agree. I was thinking of something more along these lines...
> 
> http://kmgerich.com/archive/temp/tab-mockup1.png

I preferred the favicon on the side, but I've to admit that also like this it's okay. :)

Maybe I'm just stating the obvious, but I'd like to add just one detail: the favicon shouldn't disappear if the title is longer than the tab. Camino I think handles this problem well since the text is left-aligned.

Is there already a guideline about this for Fx3? :)

Comment 73

[Dave Myron]

Why is the tab upside down and attached to the bookmarks? It implies that clicking the other tab shows a different set of bookmarks which of course it doesn't do. 

With a tab metaphor, the tab should be attached to the content related to the tab. Comment 17 asserts that tabs shouldn't be attached to a page but that's a non sequitur since the content the tab is attached to isn't a page but a viewport - and we do have one tab per viewport. 

Safari is, IMO, wrong with their inverted tabs and should not be used as a reference.

Comment 74

[Stephen Horlander [:shorlander]]

(In reply to comment #73)
> Comment 17 asserts that tabs shouldn't be attached to a page but that's a
> non sequitur since the content the tab is attached to isn't a page but a
> viewport - and we do have one tab per viewport. 
> 
> Safari is, IMO, wrong with their inverted tabs and should not be used as a
> reference.
> 
Actually I didn't say it *shouldn't* be attached to the content. I said that
having it attached to the toolbar was actually quite logical even though not
immeadiately obvious because it is uncommon. The point wasn't how we absolutely
must treat this, merely that its implementation wasn't wrong.

Whether Safari is right or wrong(and techincally it's not wrong depending on
your perspective) it is becoming quite widespread. I think the  that some
people have is that a) it creates a disconnect between content and tab(right or
wrong) and b) it isn't common(or wasn't) so therefore creates an initial sense
of strangeness. 

There are other ways to handle the situation of course. There are the
traditional tabs from the bottom. Or we could take out the space between the
page and the chrome so the tab is connected to both the viewport and the
toolbars(best of both worlds?). Or we could just go with a tabstrip with
button-esque tabs that aren't physically connected to the toolbar(s) or the
viewport.

http://www.noved.org/~stephen/theme_screenshots/alt-tabs.png

I think any of those methods would work and none of them would be "wrong". 

Comment 75

[Kevin Gerich]

Attachment: browser and toolkit theme changes, v2

addresses Dão Gottwald's comment #63

Comment 76

[Alex Faaborg [:faaborg] (Firefox UX)]

>Or we could just go with a tabstrip with
>button-esque tabs that aren't physically connected to the toolbar(s) or the
>viewport.
>http://www.noved.org/~stephen/theme_screenshots/alt-tabs.png

I like the bottom three images more than the top one, since the similar lighter grey color and lack of a top edge still causes the tab to visually group with the bookmarks toolbar items.  But I'm willing to suspend my desire for conceptually accurate tabs in favor of prettier hanging tabs if you think that is the way to go.  A completely separate issue is achieving visual differentiation from Safari.

Regardless of what the tabs may or may not be hanging off of, I think we should go with the flat tab strip shown in most of the mockups, as opposed to giving non active tabs a visual affordance (https://bugzilla.mozilla.org/attachment.cgi?id=283998).  I realize this is also a small detriment to usability, but it's a big win for simplicity.

Comment 77

[Alex Faaborg [:faaborg] (Firefox UX)]

>That has the sounds of mystery-meat navigation...

To be fair it is mystery-meat closing, not navigation :)  Simplicity and discoverability are always going to be mortal enemies.  On the mac I think we will score more points choosing simplicity when we are faced with very direct choices like this.  I wouldn't make the same recommendation on Windows.  Also, this will be considerably more discoverable than the Adium implementation since we are talking about hover on the tab, and not on the favicon itself (which is a much smaller target area).

The accidental closure problem may be annoying, but at least we have undo close tab.

Comment 78

[Wayne Woods]

(In reply to comment #77)
> Simplicity and discoverability are always going to be mortal enemies.
> On the mac I think we will score more points choosing simplicity

I guess you're using 'simplicity' as a synonym for minimalism. Because a minimal interface doesn't necessarily mean 'simple' to use. And in this case I'd say it's quite the opposite.

Comment 79

[Alex Faaborg [:faaborg] (Firefox UX)]

Yes, I mean visual simplicity, and not interactive simplicity.

Comment 80

[Wayne Woods]

(In reply to comment #74)
> http://www.noved.org/~stephen/theme_screenshots/alt-tabs.png

Thanks Stephen, I keep coming back to these, and every time I do I find that in option 1 my eyes are drawn to the active tab (good), but in the rest my attention immediately goes to the inactive tabs, giving them too much prominence (to me, anyway). So I'd support the tones used in option 1.

The buttons definitely look better when not connected to the bookmarks bar (later options), though :)

Comment 81

[Hank Mills]

Personally, I think tab attached to page is best. It evokes the idea of folders in a file cabinet. You can always change or update what is stored in a particular folder or get rid of folders, so it is consistent with experience. That being said, I may simply be justifying familiarity. I think people either get tabs or they don't and where they are attached is an aesthetics issue more than anything. 

In spite of seeing me use tabs, and my giving of explanations on how to open tabs, my family members never use tabbed browsing because they can't remember how to open a new tab. The button is on the toolbar but there is no habit. I think that lack of habit is the biggest killer, not where they attach.

Comment 82

[Hank Mills]

(In reply to comment #75)
> Created an attachment (id=284258) [details]
> browser and toolkit theme changes, v2
> 

I can't get this to build. I applied the patch and copied in the images from the  "Modified and added images" attachment and the build failed with:

+++ making chrome /Developer/moz/mozilla/CocoaFox/browser/themes/pinstripe/browser  => ../../../../dist/bin/chrome/classic.jar
file not found: /Developer/moz/mozilla/browser/themes/pinstripe/browser/skin/classic/browser/urlbar-button-background.png at /Developer/moz/mozilla/config/make-jars.pl line 428, <STDIN> line 93.
make[7]: *** [libs] Error 2
make[6]: *** [libs] Error 2
make[5]: *** [libs] Error 2
make[4]: *** [libs] Error 2
make[3]: *** [libs_tier_app] Error 2
make[2]: *** [tier_app] Error 2
make[1]: *** [default] Error 2
make: *** [build] Error 2

Comment 83

[Erin 'Folletto' Casali]

(In reply to comment #80)
> Thanks Stephen, I keep coming back to these, and every time I do I find that in
> option 1 my eyes are drawn to the active tab (good), but in the rest my
> attention immediately goes to the inactive tabs, giving them too much
> prominence (to me, anyway). So I'd support the tones used in option 1.
> 
> The buttons definitely look better when not connected to the bookmarks bar
> (later options), though :)

I agree. A "button-like" solution could be good, but it raises bigger problems in balancing the weight of the various elements.

I still think that visually a bottom attached tab is the best solution, from any point of view: prominent, top-layered active tab is a clear indication of what's active, while dimmed back-layered tabs are inactive. It couldn't be better than this.
Also, bottom-attached tabs conveys a difference between Fx & Safari, without breaking any GUI convention (since I think that's Safari breaking it). :)

While I understand that bottom-aligned tabs are a bit more difficult to integrate in a good UI layout, since they are a breaking point from the top and the bottom part of the window. :)

Comment 84

[is+mozilla]

While we're completely rewriting the Mac theme, it would be really nice if we could get long standing issues in Right-to-Left (RTL) languages resolve with this rewrite. See, for example, bugs 371841, 221824, and 364536. While I am happy to test things and provide RTL, I do not know how to write a theme. For that matter, I'm not sure how to force Minefield into RTL mode since it only ships with the en-US locale. So advice on that is probably a precondition for me to do actual testing. 

Comment 85

[Wayne Woods]

(In reply to comment #84)
While I don't personally use RTL, it would be important to finally fix that. And I'm willing to help where I can.

As far as I know, all you need to do to switch direction:
- type about:config in the location bar to go to the advanced configurator
- look for one called bidi.direction
- in LTR it has a value of 1. Double click on the value to bring up a box to change it
- Set it to 2 for RTL
- You need to restart for the chrome to reset for RTL

If there's anything else that needs to be done, I don't know.

Comment 86

[Stefan [:stefanh]]

Comment on attachment 284258 [details] [diff] [review]
browser and toolkit theme changes, v2


> 
>-.findbar-find-next {
>-  -moz-image-region: rect(0px 16px 16px 0px);
>+toolbarbutton.findbar-find-next {
>+  margin: 0;
>+  -moz-margin-start: 10px;
>+  padding: 0 !important;
> }
> 
>-.findbar-find-next:hover {
>-  -moz-image-region: rect(16px 16px 32px 0px);
>+toolbarbutton.findbar-find-next .toolbarbutton-text {
>+  margin: 0 !important;
>+  padding: 2px 8px 0 8px;
>+  background: url("chrome://global/skin/icons/round-button-left.png") no-repeat center left !important;
> }
> 
>-.findbar-find-next[disabled="true"] {
>-  -moz-image-region: rect(32px 16px 48px 0px) !important;
>+toolbarbutton.findbar-find-next:active .toolbarbutton-text {
>+  background: url("chrome://global/skin/icons/round-button-active-left.png") no-repeat center left !important;
> }
> 
> /* find-previous button */
> 
>-.findbar-find-previous {
>-  -moz-image-region: rect(0px 32px 16px 16px);
>+toolbarbutton.findbar-find-previous {
>+  margin: 0;
>+  -moz-margin-start: -1px;
>+  -moz-margin-end: 10px;
>+  padding: 0 !important;
>+  background: url("chrome://global/skin/icons/round-button-right.png") no-repeat center right !important;
> }
> 
>-.findbar-find-previous:hover {
>-  -moz-image-region: rect(16px 32px 32px 16px);
>+toolbarbutton.findbar-find-previous:active {
>+  background: url("chrome://global/skin/icons/round-button-active-right.png") no-repeat center right !important;
> }
> 
>-.findbar-find-previous[disabled="true"] {
>-  -moz-image-region: rect(32px 32px 48px 16px) !important;
>+toolbarbutton.findbar-find-previous .toolbarbutton-icon {
>+ border-left: 1px solid #a9a9a9;
>+ margin-top: 0;
>+ margin-bottom: 1px;
>+ -moz-margin-start: -1px;
>+ -moz-margin-end: 0;
> }
> 
>+toolbarbutton.findbar-find-previous .toolbarbutton-text {
>+ padding: 2px 8px 0 8px;
>+ margin: 0 !important;
>+}

You shouldn't need the "toolbarbutton" prefix here since findbar-find-previous and findbar-find-next classes are unique for toolbarbuttons - see bug 384948 where I cleaned up the file and removed stuff like this ;-)


>Index: toolkit/themes/pinstripe/global/global.css
>===================================================================
>RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/global.css,v
>retrieving revision 1.15
>diff -u -p -8 -r1.15 global.css
>--- toolkit/themes/pinstripe/global/global.css	15 Jun 2007 02:36:39 -0000	1.15
>+++ toolkit/themes/pinstripe/global/global.css	10 Oct 2007 03:01:40 -0000
>@@ -146,31 +146,32 @@ iframe {
>   height: 100px;
>   min-width: 10px;
>   min-height: 10px;
> }
> 
> /* ::::: statusbar ::::: */
> 
> statusbar {
>-  border-top: 1px solid #A3A3A3 !important;
>+  border-top: 1px solid #505050 !important;
>+  border-left: 1px solid #9C9D9C;
>+  border-right: 1px solid #9C9D9C;
>   min-width: 1px; /* DON'T DELETE!
>   Prevents hiding of scrollbars in browser when window is made smaller.*/
>   min-height: 15px !important;
>-  background-color: #FFFFFF;
>+  background: url("chrome://global/skin/statusbar-background.gif") #949393 repeat-x top left;
>   margin: 0px !important;
>   padding: 0px 16px 1px 1px;
>   -moz-appearance: none;
> }
> 
> statusbarpanel {
>   -moz-box-align: center;
>   -moz-box-pack: center;
>   padding: 0 4px;
>-  -moz-appearance: dialog;
> }

I'm not really saying that this is the wrong approach (haven't tested it), but this will affect all consumers of global.css (afaik thunderbird, calendar, seamonkey), right?

Comment 87

[Jing Jin]

I feel that the colors on the back, forward, refresh, and stop buttons look out of place compared to the rest of the interface. The general feel is dark gray metallic, but the neon-ness of the buttons seem to belong on a more cheerful/lighter interface. It might also be caused by the fact that the back/forward buttons are solid shapes, but the refresh and stop buttons are thin lines... something just looks busy and non-OS X around there =P

I also liked the search selector better when it was gray. The blue looks a little too windows, and it doesn't convey much more than the gray interaction-wise.

Basically, I just think there are a lot of extra colors on there that distract from the clean design.

Comment 88

[Rowan Mulder]

I agree with Jing Jin on the buttons; too much color is distracting especially when keeping in mind that for a large part the screen is filled with websites that sport many many colors (depending on where you go). Also it just looks like neon-light found in Tokyo or the Red Light District. The grey buttons with black icons fit well with the trends seen with Safari, iPhoto '08, and the new Finder for navigating back/forward and offers a calm feeling in the experience of the user. Basically the focus should be the website and several parts of the UI (such as a yellow bar for security), where navigation doesn't need to attract attention from the user.

As far as the tab layout, I think the current mock up by Kevin Gerich/Stephen Horlander looks good. It fits with the rare applications that use tabs in their interface (mainly Safari). Remember that most Mac/Safari users will expect the same  effect and it gives a nicer distinction between page<->browser UI. If people are concerned about that it doesn't feel 'connected' to the opened page, then we should take a look at Opera; as in fact all content (web site) related UI material should be re-ordered then (tab bar first, then location bar, then page and status bar).

I think the current mock-ups look great, and with the work done by Josh on Mac OS X widgets (and stuff) this might be one of the best Mac (fitting) browsers out there (as quite a lot of Mac users don't use Safari necessarily). Keep up the good work!

Comment 89

[Rob Campbell [:rc] (:robcee)]

the rounded buttons in the search bar are somewhat distracting. I think I'd prefer to see the "Search" button removed altogether and a light grey magnifying glass in the search box itself. Same goes for the search engine selector. Embedding it directly in the search field with a down arrow (or up/down arrows) to suggest a drop down would be preferable.

The tab-spacing is a bit extreme. I think they should be tightened up a bit.

Comment 90

[Rob Campbell [:rc] (:robcee)]

one other nit: The throbber always has a bit of "activity" on it at the top when it's not doing anything. It should be greyed-out entirely.

Comment 91

[Colin Barrett [:cbarrett]]

(In reply to comment #90)
> one other nit: The throbber always has a bit of "activity" on it at the top
> when it's not doing anything. It should be greyed-out entirely.

I'd argue that it should disappear completely when not actively throbbing -- that's what happens in other apps.

Comment 92

[Aronnax]

> I'd argue that it should disappear completely when not actively throbbing --
> that's what happens in other apps.

in which apps.?
and this would cause a problem in the Customize Sheet - it would be then there as well invisible 

----

i think the throbber should be removed from the default icon set 

actively throbbing is as well in the status bar - every tab has an own throbber

it is therefore unnecessary 
and without the throbber looks the GUI much cleaner - and cleaner is always better ;-) 

Comment 93

[Colin Barrett [:cbarrett]]

Uh, everywhere there is a throbber in the OS, if is not actively throbbing, it disappears. That's how the control works.

I'm sure that we can have it visible while customizing the sheet, but invisible when it's actually in the toolbar.



The problem, I think, with removing it from the toolbar is the case where you don't always show tabs (so if there is one tab in the window, the tab is hidden). In that case, you would have no throbber at all.

For the Mac, I'd personally recommend ripping off Safari and putting a progress bar in the background of the URL bar. No need for a throbber then!

Comment 94

[Dão Gottwald [:dao]]

(In reply to comment #93)
> The problem, I think, with removing it from the toolbar is the case where you
> don't always show tabs (so if there is one tab in the window, the tab is
> hidden). In that case, you would have no throbber at all.

Collapsing the throbber if the tabbar is not collapsed would be trivial.

Comment 95

[Erin 'Folletto' Casali]

(In reply to comment #93)
> For the Mac, I'd personally recommend ripping off Safari and putting a progress
> bar in the background of the URL bar. No need for a throbber then!

I completely agree. The loader under the location bar is a wise choice. Personally, I think it should be ported also on Firefox/win and Firefox/linux, since it has a better affordance and it's exacly where the user has its attention in that moment. :)

The throbber so will be present only on the tabs, since it's needed to show which ones are loading, and which are not.

Comment 96

[Colin Barrett [:cbarrett]]

(In reply to comment #94)
> (In reply to comment #93)
> > The problem, I think, with removing it from the toolbar is the case where you
> > don't always show tabs (so if there is one tab in the window, the tab is
> > hidden). In that case, you would have no throbber at all.
> 
> Collapsing the throbber if the tabbar is not collapsed would be trivial.

Now *there's* a good idea!

Comment 97

[Aronnax]

(In reply to comment #93)
> Uh, everywhere there is a throbber in the OS, if is not actively throbbing, it
> disappears. That's how the control works.

Ok, in the finder for example, but it is on a complete different location - compare it for example with Camino or Omniweb - they have as well a throbber but it will as well never complete disappear - it looks simply strange on the toolbar "with nothing" when it not active 

> I'm sure that we can have it visible while customizing the sheet, but invisible
> when it's actually in the toolbar.

> 
> The problem, I think, with removing it from the toolbar is the case where you
> don't always show tabs 

in the status bar is still the same stuff - only not with a throbber

(so if there is one tab in the window, the tab is
> hidden). In that case, you would have no throbber at all.
> 
> For the Mac, I'd personally recommend ripping off Safari and putting a progress
> bar in the background of the URL bar. No need for a throbber then!
>

why not - i`m not a fan from this, but most user will likely love it   

Comment 98

[Dão Gottwald [:dao]]

(In reply to comment #96)
> (In reply to comment #94)
> > (In reply to comment #93)
> > > The problem, I think, with removing it from the toolbar is the case where you
> > > don't always show tabs (so if there is one tab in the window, the tab is
> > > hidden). In that case, you would have no throbber at all.
> > 
> > Collapsing the throbber if the tabbar is not collapsed would be trivial.
> 
> Now *there's* a good idea!

OK, filed as bug 400398! :)

Comment 99

[Aronnax]

(In reply to comment #96)
> (In reply to comment #94)
> > (In reply to comment #93)
> > > The problem, I think, with removing it from the toolbar is the case where you
> > > don't always show tabs (so if there is one tab in the window, the tab is
> > > hidden). In that case, you would have no throbber at all.
> > 
> > Collapsing the throbber if the tabbar is not collapsed would be trivial.
> 
> Now *there's* a good idea!
> 

and the result would be a dithering toolbar - many parts will then to bop around -  it is not a good idea ;-)  

Comment 100

[RobertJ]

Don't mean to intrude here but don't eliminate the drop markers on the back/forward buttons. I know Safari doesn't have them but Safari is a lame browser with many missing features.

Comment 101

[Federico B P]

It's not a missing feature, the feature is there, you just have to hold down your mouse button.

Comment 102

[RobertJ]

(In reply to comment #101)
> It's not a missing feature, the feature is there, you just have to hold down
> your mouse button.
> 
Thanks, I just realized that; however, will this OS dependent toolbar etc cause extension developers that place icons on the toolbars to focus on Win since Mac and Linux shares are small by comparison? Just a thought.

Comment 103

[Colin Barrett [:cbarrett]]

Now that unified's in, the ball is in yalls court ;)

Comment 104

[Mike Beltzner [:beltzner, not reading bugmail]]

I believe the best approach here would be to get an updated patch, or ideally now that unified is in, a JAR which people can install on their nightly builds as a theme.

Comment 105

[Kevin Gerich]

Attachment: browser and toolkit theme changes, v3

Here's an updated patch for the main browser window. 

A stand-alone theme jar is available here:
http://kmgerich.com/archive/temp/proto_0.6.jar

Comment 106

[Kevin Gerich]

Attachment: Images to go with v3 patch

Comment 107

[Colin Barrett [:cbarrett]]

I notice a small visual glitch on my machine when creating a new tab (look at the bottom of the tab bar)

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9a9pre) Gecko/2007103104 Minefield/3.0a9pre

(yay for the version of OS X being in the UA now!)

Comment 108

[Colin Barrett [:cbarrett]]

So is this going to make beta 1? If not, what the heck was the point of unified blocking M9?

I was under the impression I was the long pull?

Comment 109

[Simon Strandman]

Hello

I tried v3 and have some minor problems:

If you hide the bookmarks toolbar the tabs does not blend in very well and look a bit weird as they have a brighter color.

Some of the search provider's logos in the search box has white squares around them.

Also several leopard apps using this style fade out when they are not focused (finder, safari etc), firefox does not.

Comment 110

[Dão Gottwald [:dao]]

Comment on attachment 286931 [details] [diff] [review]
browser and toolkit theme changes, v3

In case you want beltzner's feedback, ui-review is your flag.
In case you want a code review, don't ask beltzner.

Comment 111

[Colin Barrett [:cbarrett]]

(In reply to comment #109)
>
> Also several leopard apps using this style fade out when they are not focused
> (finder, safari etc), firefox does not.

We'd need to add some sort of DOM event for unfocus/focus. I proposed this in some other bug but heard it'd be hard or something? Doesn't make a lot of sense, since we're doing something like this anyway for bug 54488, though it's all in C++ code.

Comment 112

[Colin Barrett [:cbarrett]]

(In reply to comment #107)
> I notice a small visual glitch on my machine when creating a new tab (look at
> the bottom of the tab bar)
> 
> Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9a9pre)
> Gecko/2007103104 Minefield/3.0a9pre
> 
> (yay for the version of OS X being in the UA now!)

If you cause a new tab to be created by clicking on some link outside the browser, the glitch persists until the page has finished loading.

Comment 113

[Stefan [:stefanh]]

Comment on attachment 286931 [details] [diff] [review]
browser and toolkit theme changes, v3

+#historyTree treechildren::-moz-tree-row(selected,focus),
+#bookmarks-view[type="single-column"] treechildren::-moz-tree-row(selected,focus) {  
+  background: url("chrome://global/skin/icons/tree-selected-overlay.png") -moz-mac-alternateprimaryhighlight repeat-x center center !important;
+  color: #fff !important;

I've removed all traces of "-moz-mac-alternateprimaryhighlight" in toolkit (See bug 379985) since it's now possible to use "Highlight" instead  (and HighlightText works too).  :-)

 menubar {
-  -moz-appearance: toolbar;
   min-width: 1px;
 }

Just wondering if this is intentional? This style rule is for a xul menubars like the one in http://www.mozilla.org/docs/tutorials/sitenav/4.xul.

Hmm, all those id rules in global.css, should they be there?

Comment 114

[Phil Ringnalda (:philor)]

I certainly hope that those browser-specific rules using the most expensive selectors possible in global.css mean an automatic r-, since among other things you're making every single selection of an email folder or an email in the Thunderbird threadpane cause the style system to walk clear up to the top of the DOM to see if there's an element with id="bookmarks-view" anywhere above the tree.

Instead, if you need pinstripe-specific CSS files where you don't want to add an xml-stylesheet for everyone, you should be able to use

  skin/classic/browser/sidebar.css
% style chrome://browser/content/bookmarks/bookmarksPanel.xul chrome://browser/skin/sidebar.css

in browser/themes/pinstripe/browser/jar.mn, which will also let you get rid of the sure sign of having your selector in too broad a CSS file, element#id.

Comment 115

[Kevin Gerich]

Comment on attachment 286931 [details] [diff] [review]
browser and toolkit theme changes, v3

Thanks for the advice Dão, Stefan and Phil. I'll incorporate your recommendations into the next patch.

Comment 116

[is+mozilla]

OK, I finally had the chance to try out the new theme in RTL mode. Basically, it seems that nothing is working. :( Actually, that's too harsh. Many things are working, but there are several major glitches in the main browser window that render the theme inhospitable to RTL users: 
1) All buttons in the toolbar (forward/back/go) are still in the LTR orientation.
2) The search-engine icon and search button are rounded towards rather than away from the search field. (I guess this is the same as #1.)
3) Tab bar: the corners are rounded towards rather than away from the tab itself.
4) URL bar: this actually has a complete RTL orientation, except that is wrong, as all (or almost all) urls are in English. It should be favicon on the left, url left-justified and rendered as LTR text, the drop down list on the right. In the screen shot you'll notice that the trailing slash appears on the left of the url rather than the right, the tell-tale sign of English text rendered as RTL instead of LTR. 

I think all of 1-3 should be easy to fix, as I recall there are forward-rtl, back-rtl, etc. icons that can be set. For paired icons, just reverse the identities for the icons. For others (go?, search buttons?) you may have to do a horizontal reflections to create new icons. For 4, I'm not sure what's involved, but gtkstripe does it correctly by default so I think the ability should be built-in to gecko. 

If you make any RTL changes, I'd appreciate it if you would make that clear in the comment so I know to check out the new version. I'll try to reply faster from now on.

Comment 117

[Derek Dawkins]

One minor problem I've noticed is that the pinstripes still aren't gone on Leopard. All pinstripes have been removed from Leopard, so the ones remaining with this new skin make it feel slightly out of place. Additionally, context menus are not rounded as they are in Leopard. These are minor issues, but for all of the work that has gone into this dramatic new look it would be a shame to ignore the details.

Comment 118

[Reza Jelveh]

(In reply to comment #112)

> If you cause a new tab to be created by clicking on some link outside the
> browser, the glitch persists until the page has finished loading.
> 

i have noticed this glitch too. apparently ff doesn't like the padding: 0px;

--- browser/browser.css 2007-11-01 03:33:53.000000000 +0100
+++ browser/browser.css    2007-11-07 17:54:25.000000000 +0100
@@ -986,7 +986,9 @@
   -moz-appearance: none;
   color: #383838;
   -moz-box-pack: center;
-  padding: 0px;
+  padding-top: 0px;
+  padding-left: 0px;
+  padding-right: 0px;
   border: none !important;
   height: 26px !important;
   min-width: 1px !important;
@@ -1049,7 +1051,7 @@
 }

this works however it causes another visual glitch below the close button:

http://img84.imageshack.us/my.php?image=picture6ru4.png

Comment 119

[Reza Jelveh]

another quick update the following seems to fix the sideeffect i was having:

@@ -1115,7 +1115,7 @@
   -moz-appearance: none;
   border: none !important;
   padding: 0px;
-  margin: 0 0 4px 0;
+  margin: 0 -1px 0 -1px;
   background: inherit;
   cursor: default;
 }
more or less anyway...

Comment 120

[Simon Strandman]

> Additionally, context menus are not rounded as they are in Leopard. These are 
> minor issues, but for all of the work that has gone into this dramatic new look > it would be a shame to ignore the details.

Also the menus in leopard have a blurred transparency while the context menus in firefox don't. Not a big deal though.

Comment 121

[Samuel Sidler (old account; do not CC)]

(In reply to comment #120)
> Also the menus in leopard have a blurred transparency while the context menus
> in firefox don't. Not a big deal though.

That's covered in bug 391984.

Comment 122

[Reza Jelveh]

another issue the add bookmarks thingy lacks the disclosure buttons for the dropdown menus or whatever its called.

Comment 123

[Stefan [:stefanh]]

(In reply to comment #115)
> (From update of attachment 286931 [details] [diff] [review])
> Thanks for the advice Dão, Stefan and Phil. I'll incorporate your
> recommendations into the next patch.
> 

Just a fyi: I forgot to mention that the patch restyled seamonkey's sidebar/bookmarks manager :-) That's another reason why the browser-specific rules should go somewhere in /browser (seamonkey and ff seems to use the same id's...)

Comment 124

[Dave Townsend [:mossop]]

The changes with the latest version of the theme to the options dialog, styling it as unified with blended pane selector should also be applied to the page info and add-ons dialogs.

Comment 125

[Eduard Grebe]

My apologies if this is not the appropriate forum or if you know of the issue already. Firefox 3 beta 1 on Leopard does not use the default leopard colour scheme — the title and toolbar background is significantly lighter than other apps. This looks quite jarring.

Comment 126

[Chris Blore]

(In reply to comment #125)
> My apologies if this is not the appropriate forum or if you know of the issue
> already. Firefox 3 beta 1 on Leopard does not use the default leopard colour
> scheme — the title and toolbar background is significantly lighter than other
> apps. This looks quite jarring.
> 

This is intentional I believe. The patch necessary for this was not checked in until after the beta builds were produced.

Comment 127

[Patrick]

(In reply to comment #125)
> My apologies if this is not the appropriate forum or if you know of the issue
> already. Firefox 3 beta 1 on Leopard does not use the default leopard colour
> scheme — the title and toolbar background is significantly lighter than other
> apps. This looks quite jarring.
> 


This is indeed a bug, see bug 402729

Comment 129

[Phil Ringnalda (:philor)]

Comment on attachment 286931 [details] [diff] [review]
browser and toolkit theme changes, v3

+  <binding id="tabbrowser-tab" extends="chrome://browser/content/tabbrowser.xml#tabbrowser-tab">
+    <content>

As bug 405137 pointed out for the prototype, that means you lose the |chromedir="&locale.dir;" closetabtext="&closeTab.label;"| from tabbrowser.xml, so you get an empty tooltip over the close button. No way to get them localized in the prototype, but here you should be able to just include them in your binding.

Comment 130

[Chris Blore]

Just a note to say that Proto is broken by the recently checked-in patch for bug 398020

Comment 131

[[e-mail]]

Proto (tested version 0.6 from bugzilla and 0.7 from addons.mozilla.org) seems to introduce some problems with Chinese (and possibly other East Asian language) support that does not happen on the "default" theme that ships with Firefox 3.0 beta 1 (Build 2007110903).

Chinese text in the chrome (and sometimes in the content) sometimes mysteriously morph between sans-serif and serif types.  By default, Mac OS X in Chinese uses sans-serif fonts and Firefox should respect this unless a webpage specifies otherwise.

Without any real experience of developing anything I have no idea what's wrong though.

Perhaps towards the end of the development it could be worth checking this a bit further to ensure that it works across languages and platforms.

I am using:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1

Comment 132

[Darren VanBuren]

The theme looks great, but I am Mac-less in Seattle until christmas. integrating the stop into reload will be even more realistic. Firefox 3 should be out by then, and this theme will be in the new release.

Comment 133

[Fred Wenzel [:wenzel]]

Attachment: Recent address and search bar flaws introduced in minefield

I am not entirely sure why this happens, but the new theme's address and search bars have apparent flaws since a few days (I believe it was the nightly update from 11/23 that introduced them.

Anyone experience the same?

Comment 134

[Chris Blore]

Yes I have. See comment #130. I should (In reply to comment #133)
> Created an attachment (id=290239) [details]
> Recent address and search bar flaws introduced in minefield
> 
> I am not entirely sure why this happens, but the new theme's address and search
> bars have apparent flaws since a few days (I believe it was the nightly update
> from 11/23 that introduced them.
> 
> Anyone experience the same?
> 

Yes I have. See comment #130. Hopefully a new Proto version will be available soon.

Comment 135

[Simon Howes]

Seems to have broken most themes, Aronnax's being a good example.

Comment 136

[Yann]

(In reply to comment #111)
> (In reply to comment #109)
> >
> > Also several leopard apps using this style fade out when they are not focused
> > (finder, safari etc), firefox does not.
> 
> We'd need to add some sort of DOM event for unfocus/focus. I proposed this in
> some other bug but heard it'd be hard or something? Doesn't make a lot of
> sense, since we're doing something like this anyway for bug 54488, though it's
> all in C++ code.

I would agree fade out would need to occur for Leopard. This is one of the neat UI changes for Leopard, and Firefox does look weird in behavior compared to other apps.

Other than that, great job, really.

Comment 137

[Marcia Knous [:marcia]]

I am viewing the theme for the first time on Leopard using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b2pre) Gecko/2007112604 Minefield/3.0b2pre, and I noticed there is a gap between where the tab ends and the page begins. Is that intentional?

Comment 139

[Eduard Grebe]

Attachment: line in address bar

The line next to the site logo/thumbnail in the address bar look strange when it has no background.

Comment 140

[Alex Faaborg [:faaborg] (Firefox UX)]

>The line next to the site logo/thumbnail in the address bar look strange when
>it has no background.

The current plan is to style that like a button, identical to the styling of the search engine button in proto.

For people who don't regularly read planet.mozilla.org, cross platform changes to the Firefox 3 UI are being discussed here:

http://blog.mozilla.com/faaborg/2007/11/15/the-shape-of-things-to-come/

Comment 141

[Marcia Knous [:marcia]]

Is there a reason that the Report a Broken website icon is the only one not styled for the theme - it that in process?

Comment 143

[Chris Blore]

Just to note that bug 406121 (just duped to this bug) concerns the fact that the new url autocomplete patch breaks Proto. 

Comment 144

[Chris Blore]

Just to note that bug 406121 (just duped to this bug) concerns the fact that the new url autocomplete patch does not work with Proto. 

Comment 145

[eatsleepgame]

I don't know where else to ask, but is there any progress on getting this working with the newest nightly builds?

Comment 146

[Jennifer]

At http://www.takebacktheweb.org you can download a version of GrApple (as of right now, 0.8.9) that works with nightly builds. This is what I have had to do in order to advance from the Nov 21 build which is the last one that works with the official Proto theme. It's not an optimal answer, but it is better than nothing.

Comment 147

[Johnathan Nightingale [:johnath]]

Attachment: EV broken in Proto 0.8

Just grabbed proto 0.8 and it looks great.  Nice to see the site button matching the search bar pulldown.  However, when identity-icon-label ( http://mxr.mozilla.org/mozilla/source/browser/base/content/browser.xul#285 ) is unhidden for EV (or depending on how bug 406612 resolves, on regular SSL as well) there is some obvious bustage.

To test EV behaviour yourself, set the NSS_EV_TEST_HACK as described in bug 404592 comment 2 and then visit an EV site like https://www.paypal.com, https://www.schwab.com or https://www.britishairways.com

Comment 148

[Colin Barrett [:cbarrett]]

Proto 0.8 is really slick, but it shouldn't be applying the unified styling to very window! Makes windows like View Source look rather odd.

See bug 406828 for some info.

Comment 149

[Jesse Ruderman]

I get some errors from browser.css with Proto 0.8 on trunk.  (They appear on the console when I run a debug build.)

(1) CSS Error (chrome://browser/skin/browser.css :71.11): Unexpected token in attribute selector: '#searchbar'.  Ruleset ignored due to bad selector.

Due to an incomplete rule: "#searchbar[focus"

(2) CSS Error (chrome://browser/skin/browser.css :592.33): Error in parsing value for property 'background-position'.  Declaration dropped.

Due to "background-position: 4px right"

Comment 150

[is+mozilla]

Attachment: Broken RTL interface in Proto 0.8.

Just tested version 0.8 of proto in both b1 and most recently nightly. All of the issues with RTL persist.

Comment 151

[is+mozilla]

Attachment: how it should look in RTL

For comparison, here is a screen shot of the Ubuntu Tango Theme, also running on OS X. Notice hor most buttons are reversed, but the actual url button remains LTR. 
(PS: if the good folks at Ubuntu can get a bidi theme, surly Mozilla can as well.)

Comment 152

[Eduard Grebe]

Attachment: major glitches in proto 0.8

As you can see in this image, three major glitches are immediately visible in proto 0.8. On the right end of the address bar (under the arrow) the bottom does not line up. The google logo of the search box is not aligned properly. And the thick verticle bar inside the search box.

Comment 153

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

I've seen the same yesterday after the update to version 0.8. But after a restart the wrong positioning was gone. Could this happen while having used a former version and old styles were active? Eduard, does a restart also solve your problem?

Comment 154

[Alex Faaborg [:faaborg] (Firefox UX)]

>Created an attachment (id=292215) [details]
>major glitches in proto 0.8

I believe that is what proto 0.8 looks like when running in beta 1, if you switch over to Gecko/2007120704 Minefield/3.0b2pre everything should appear correctly.

Comment 156

[Dão Gottwald [:dao]]

0.8 shouldn't have been marked compatible with 3.0b1.

Comment 157

[Mike Marco]

Attachment: Small glitches in Proto 0.8.1

Three minor nitpicks:

1. Very small vertical line visible on mouse over in the Bookmarks Toolbar, as if the end cap on the left doesn't quite line up. This visual artifact does not appear on mouse click.

2. Shouldn't the tab close button be on the left, for platform consistency? Also, if you look very closely, the drop shadow at the bottom of the tab is missing in the region immediately below the button.

3. The top and bottom edges of the search field are fuzzy (not as sharp or well-defined) compared to the top and bottom edges of the location field.

Great theme otherwise! Can't wait to see the finished product in Firefox 3.

Using Proto 0.8.1 on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b2pre) Gecko/2007121008 Minefield/3.0b2pre.

Comment 158

[cris]

I might as well just throw my complain about this theme here, 

first, the whole concept of this theme is bad. safari-mimicking is not a good way to go.

second, about being "native"

tiger's native is aqua, no unification
leopard native is brushed metal, unified

which means this theme will not be native on Tiger. because native on leopard is NOT native on Tiger.

last: 

if firefox mac design team is just so eager to pretend to be safari, at least consider my comment on the design:

on this theme in its current incarnation, there are way too many curves, too heavy shadows, too many line, the whole UI is extremely crowded.

remember, safari UI is clean, yes, and color-less, thats fine, and safari is extremely limited when it comes down to what user can do with the toolbar, or how much stuff/tools/information users can expected from toolbar. which is NOT the case for firefox. 

Comment 159

[Wayne Woods]

(In reply to comment #158)
If mimicking Safari was all there ever was to this theme, I might feel the same way. But from what I understand, the theme development is split into stages. The first stage was to get it looking "native" (almost done), and the come the tweaks to visually differentiate it from other native apps, including Safari and to remove any rough edges. The latter stage may involve colour (hopefully). Correct me if I got that wrong, or if the plan has changed since.

But as for individual nits with the styling and images, it would be handy to address each one specifically... for example, which curves or shadows look out of place and how they would look better.

Comment 160

[Alex Faaborg [:faaborg] (Firefox UX)]

[comment #157]
>Created an attachment (id=292516) [details]
>Small glitches in Proto 0.8.1

Mike, this is really great feedback, both in terms of attention to detail, and presentation.

[comment #159]
>But from what I understand, the theme development is split into stages.
>The first stage was to get it looking "native" (almost done), and the come the
>tweaks to visually differentiate it from other native apps, including Safari

Stage two will be to work on maintaining Firefox's visual identity across platforms, and differentiating it from the native browsers on each platform (Safari, IE).  However instead of using color, we are planing on leveraging shape for identity.  Here is more detail about some of our current thoughts about the cross platform control layout:

http://blog.mozilla.com/faaborg/2007/11/15/the-shape-of-things-to-come/

Comment 161

[Reza Jelveh]

(In reply to comment #157)
> 1. Very small vertical line visible on mouse over in the Bookmarks Toolbar, as
> if the end cap on the left doesn't quite line up. This visual artifact does not
> appear on mouse click.

this glitch has actually been around from the start and i'm wondering if it's actually a theme bug or a small ff bug, since comment #112 and comment #113 fix it.

you could try out this:
http://rapidshare.com/files/75795956/proto_for_mac_os_x-0.8.1-fx-macosx.jar.html
(sorry the attachment size limit is 300k)
it should make the glitch disappear but im having the feeling that the text inside the tabs is a pixel too high.

Comment 162

[Reza Jelveh]

uh sorry i meant #118 and #119 :/

Comment 163

[Oakwine]

My two nits:

1. When rearranging tabs by drag and drop, the drop indication arrow is the old green arrow, which is also hard to find when placed over this theme.

2. When clicking the star twice, the 'reveal list of folders' icon next to the Folder drop-down is invisible, but still can be clicked to reveal the full list of folders.

Comment 164

[cris]

please, people, Tiger is different from leopard, maybe under leopard it looks pretty native like iTunes.

But under Tiger, the color of title bar doesn't even match the color of toolbar! how exactly do you call that "native"?

Comment 165

[Reza Jelveh]

(In reply to comment #164)
> But under Tiger, the color of title bar doesn't even match the color of
> toolbar! how exactly do you call that "native"?
> 
uh... that's not true. i've been using it before i switched to leopard. try deleting your userChrome.css maybe?

besides, there isn't really a "native" unified(as in unified across the os not the toolbar look...) look pre leopard. and imho safari in tiger isn't sharing the look other applications have either and it blends in nicely. 

Comment 166

[cris]

huh, interesting, I though userChrome.css is not there by default? but any how, if you say so, i will give it a try.

Comment 167

[cris]

(In reply to comment #165)
> (In reply to comment #164)
> > But under Tiger, the color of title bar doesn't even match the color of
> > toolbar! how exactly do you call that "native"?
> > 
> uh... that's not true. i've been using it before i switched to leopard. try
> deleting your userChrome.css maybe?
> 
> besides, there isn't really a "native" unified(as in unified across the os not
> the toolbar look...) look pre leopard. and imho safari in tiger isn't sharing
> the look other applications have either and it blends in nicely. 
> 
nope, there is no userchrome.css for me, I even deleted userchrome-example.css

now take a look at the screenshot.

maybe you didn't notice, but the color title bar is lighter than toolbar.
http://img161.imageshack.us/img161/9626/picture3sy2.png

Comment 168

[Reza Jelveh]

looks like the the color of the address bar should be lighter than it is on your box.
while we're at it, if you turn off the bookmark bar, the active tabs color does not match the address bars making it look wrong.

Comment 169

[cris]

1. titles bar's color is different from toolbar, im not sure if this is unique to my machine, I think of no reason why? i didn't use anything like UNO. somebody else can check and see if this mis-match happen to them as well

2. I think Im not the only one who turn off bookmarks bar, and this should be taken into consideration when they developing the theme.

3. eventually, it comes down to leopard and tiger has different "gray-ness", so firefox can not use a fixed design to be native on both leopard and tiger. IMHO, the whole brushed metal is the wrong way from the beginning.

Comment 170

[cris]

(In reply to comment #169)
> 1. titles bar's color is different from toolbar, im not sure if this is unique
> to my machine, I think of no reason why? i didn't use anything like UNO.
> somebody else can check and see if this mis-match happen to them as well
> 
> 2. I think Im not the only one who turn off bookmarks bar, and this should be
> taken into consideration when they developing the theme.
> 
> 3. eventually, it comes down to leopard and tiger has different "gray-ness", so
> firefox can not use a fixed design to be native on both leopard and tiger.
> IMHO, the whole brushed metal is the wrong way from the beginning.
> 

I checked the other mac I have, which looks fine

so, now its getting weird, why this machine show this color mismatch?

Comment 171

[Colin Barrett [:cbarrett]]

To people complaining about a color mismatch:

What version of Firefox are you using, and do you have the color management pref turned on?

Comment 172

[cris]

(In reply to comment #171)
> To people complaining about a color mismatch:
> 
> What version of Firefox are you using, and do you have the color management
> pref turned on?
> 

interesting, you nailed it. now, is this gonna be a issue in the final version?

also, any plan for color mismatch caused by disable of bookmark bar?

Comment 173

[Colin Barrett [:cbarrett]]

Color management and unified not looking right is bug is 403169. It will be fixed by release.

Comment 174

[Eduard Grebe]

The latest nightly build of Minefield.app is telling me that it is not compatible with Proto 0.8.1. (I was using just the previous day's build before.) Is anyone else experiencing this?

Comment 175

[Chris Blore]

(In reply to comment #174)
> The latest nightly build of Minefield.app is telling me that it is not
> compatible with Proto 0.8.1. (I was using just the previous day's build
> before.) Is anyone else experiencing this?
> 

This is because the Minefield version number was increased to 3.0b3pre. You can fix this by going to the install.rdf file in your profile folder and increasing the maxversion to 3.0b3pre.

Comment 176

[Marcia Knous [:marcia]]

Using Proto 0.8.2 and the Beta 2 candidate, when I switch to the Error Console or Add Ons manager, Spaces switches me that dialog directly and minimizes the app. This does not happen with the default theme - the dialog comes up in front of the Firefox App.

Comment 177

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #175)
> (In reply to comment #174)
> > The latest nightly build of Minefield.app is telling me that it is not
> > compatible with Proto 0.8.1. (I was using just the previous day's build
> > before.) Is anyone else experiencing this?
> > 
> 
> This is because the Minefield version number was increased to 3.0b3pre. You can
> fix this by going to the install.rdf file in your profile folder and increasing
> the maxversion to 3.0b3pre.

I don't understand why you'd tell him to do that, when he should really just upgrade to the new 0.8.2 version:

https://addons.mozilla.org/en-US/firefox/addon/6050

Comment 178

[Chris Blore]

(In reply to comment #177)
> (In reply to comment #175)
> > (In reply to comment #174)
> > > The latest nightly build of Minefield.app is telling me that it is not
> > > compatible with Proto 0.8.1. (I was using just the previous day's build
> > > before.) Is anyone else experiencing this?
> > > 
> > 
> > This is because the Minefield version number was increased to 3.0b3pre. You can
> > fix this by going to the install.rdf file in your profile folder and increasing
> > the maxversion to 3.0b3pre.
> 
> I don't understand why you'd tell him to do that, when he should really just
> upgrade to the new 0.8.2 version:
> 
> https://addons.mozilla.org/en-US/firefox/addon/6050
> 

At the time, 0.8.1 was the most recent version so I changed the maxversion. Now that the updated version of Proto has been released, that is obviously irrelevant.

Comment 179

[Darren VanBuren]

Attachment: Proto 0.8.2 under windows

Works, slightly buggy, under Windows! Would make a great theme to download for Windows, but menus are transparent. Looks good though!

Comment 180

[Albert R.]

(In reply to comment #136)
> (In reply to comment #111)
> > (In reply to comment #109)
> > >
> > > Also several leopard apps using this style fade out when they are not focused
> > > (finder, safari etc), firefox does not.
> > 
> > We'd need to add some sort of DOM event for unfocus/focus. I proposed this in
> > some other bug but heard it'd be hard or something? Doesn't make a lot of
> > sense, since we're doing something like this anyway for bug 54488, though it's
> > all in C++ code.
> 
> I would agree fade out would need to occur for Leopard. This is one of the neat
> UI changes for Leopard, and Firefox does look weird in behavior compared to
> other apps.
> 
> Other than that, great job, really.
> 

If I can chime in here, I think that the light grey fadeout is a necessary add.  Right now it is somewhat jarring when another app has active focus (e.g. Safari) and Firefox is in the background with a similar shade of grey - no longer as easy to tell who's on top.

I also would prefer close widget on the left of the tab, but I think that's pretty well known by now :)

Otherwise, I'm really pleased with how things are coming along.  Good stuff!

Comment 181

[Marcia Knous [:marcia]]

Do we have an ETA on when the theme will be integrated into the nightlies?

Comment 182

[Darren VanBuren]

Once the address bar is fixed. Now instead of the two line per entry implemented into the default theme everything gets squished on one line. Also Fission needs to work. I'll post a screenshot.

Comment 183

[Bart]

Adding a bookmark doesn't work for me with the Proto theme.  I originally thought it was a Firefox issue and opened a separate bug (https://bugzilla.mozilla.org/show_bug.cgi?id=409306), but I have since narrowed it down to using Proto.

When adding a bookmark, I am not able to select folders -- there's no arrow to open up a folders list, and the dropdown list of folders only has a couple of entries in it.  The default Firefox theme works fine.

I'll upload a picture.

Comment 184

[Bart]

Attachment: Add Bookmarks dialog doesn't have a way to select additional folders.

Comment 185

[Oakwine]

(In reply to comment #183)

> When adding a bookmark, I am not able to select folders -- there's no arrow to
> open up a folders list, and the dropdown list of folders only has a couple of
> entries in it.  The default Firefox theme works fine.

Workaround: the arrow is there, but it is invisible.  You can still click where the arrow should be to activate the folder picker.

Comment 186

[Dão Gottwald [:dao]]

Kevin: As you update the theme, please take bug 393718 into account.

Comment 187

[Johnathan Nightingale [:johnath]]

(In reply to comment #147)
> Created an attachment (id=292069) [details]
> EV broken in Proto 0.8
> 
> Just grabbed proto 0.8 and it looks great.  Nice to see the site button
> matching the search bar pulldown.  However, when identity-icon-label (
> http://mxr.mozilla.org/mozilla/source/browser/base/content/browser.xul#285 ) is
> unhidden for EV (or depending on how bug 406612 resolves, on regular SSL as
> well) there is some obvious bustage.
> 
> To test EV behaviour yourself, set the NSS_EV_TEST_HACK as described in bug
> 404592 comment 2 and then visit an EV site like https://www.paypal.com,
> https://www.schwab.com or https://www.britishairways.com

This still appears to be broken in proto 0.9.1.  I think all that needs to be done is for the styling on identity-box to stretch the button gradient-fill horizontally to fit the label here:

http://mxr.mozilla.org/mozilla/source/browser/base/content/browser.xul#287

Comment 188

[Marcia Knous [:marcia]]

Just downloaded version 0.9.1. Using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre) Gecko/2008011704 Minefield/3.0b3pre, if you switch the toolbar icons to "icons and text," the "forward" text under the icon is noticeably misaligned.

In a separate note, I think the grey "Go to the address" widget in the location bar will be missed by many, since to me it looks as if it is greyed out.

Comment 189

[Aronnax]

Hi, 
i love the new Add-ons, Page Info, Error Console windows ;-)
only one small suggestion:
the white list style looks a little bit boring and unfinished 
for example:
http://www.takebacktheweb.org/themes/stuff/add-on.png 
the second image is the refinement suggestion 
i changed it in my GrApple (Gran Paradiso Outlook) 0.8.9.7 theme, when someone wants to try it http://www.takebacktheweb.org/

-----

The kind of way, how the rounded search fields are build (only with code) is really interesting, but i disbelief that it will ever achieve the same kind of quality as a solution with images. 
A great work, but unfortunately not good enough compared with an image solution. It should be changed ;-)  

Cheers  

Comment 190

[Alex Faaborg [:faaborg] (Firefox UX)]

>the white list style looks a little bit boring and unfinished 
>for example:
>http://www.takebacktheweb.org/themes/stuff/add-on.png 

That looks really good :)

Comment 191

[Yann]

Just downloaded 0.9.1,with FF 3b2 and Leopard.

I noticed that the download manager got screwed up. The icons next to downloaded files are looking awful and unreadable, and there are 4 of them instead of 2.

Other than that, great work!!! Still looking forward to the change of color when Firefox loses focus, but I know I am not the only one ;-).

Comment 192

[Dão Gottwald [:dao]]

Are there plans for making the selected tab not look out of place when the bookmarks toolbar is collapsed?

(In reply to comment #157)
> Created an attachment (id=292516) [details]
> 3. The top and bottom edges of the search field are fuzzy (not as sharp or
> well-defined) compared to the top and bottom edges of the location field.

This is still the case.

Comment 193

[Dão Gottwald [:dao]]

In icons+text mode, the back and forward icons are misaligned. Note that I'm using proto on Windows, but I don't think that's causing the problem.

Bug 402992 and bug 393718 are yet to be fixed in proto.

Comment 194

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: toolbar is being truncated in popup windows on Tiger

Note that the toolbar is being truncated in popup windows on Tiger

Comment 195

[Aronnax]

(In reply to comment #194)
> Created an attachment (id=298008) [details]
> toolbar is being truncated in popup windows on Tiger
> 
> Note that the toolbar is being truncated in popup windows on Tiger
> 

and not only in Tiger 
the margin-top: -4px; in browser.css 
#nav-bar {
  background-color: #969696;
  border-bottom: 1px solid #404040;
  background-image: url("chrome://global/skin/toolbar/toolbar-background.gif");
  background-repeat: repeat-x;
  background-position: 4px right;
  margin-top: -4px;
  padding: 0 4px;
}
is the reason (and necessary for the style) 

i fixed the same problem it in my theme with an additional    
min-height: 37px !important; in #nav-bar 

Cheers 

Comment 196

[Tomer Harpaz]

Attachment: 3D favicon stays in 'pressed' state

3D favicon button stays in 'pressed' state after it is dragged to create a link

Comment 197

[Shawn Wilsher :sdwilsh]

The download manager no longer seems to have the search text when it is empty and inactive.

Comment 198

[Aronnax]

Hi, 
another suggestion:
the star menu bookmarks tree view could need some color 

for example:
http://www.takebacktheweb.org/themes/stuff/star_menu.png

GrApple (Gran Paradiso Outlook)- 0.9 have these changes http://www.takebacktheweb.org/ - when someone
wants to try it

Cheers 

Comment 199

[Steuard Jensen]

I just started testing Proto 0.9.1 a few days ago (I had been using the default theme), and I noticed one problem early on: when typing text into the awesomebar, the matching text isn't highlighted in the suggested links. All I see is an extra space before and after the matching text. For example, if I type "ime", the top suggestion is "The New York T ime s". That "ime" ought to be bold and underlined as in the default theme, or something that stands out similarly well (the spaces may be helpful too, but they aren't enough on their own).

Comment 200

[Hank Mills]

(In reply to comment #199)
> That "ime" ought to
> be bold and underlined as in the default theme,


It shows as bold and underlined for me in a build from today.

Comment 201

[Steuard Jensen]

(In reply to comment #200)
> (In reply to comment #199)
> > That "ime" ought to be bold and underlined

> It shows as bold and underlined for me in a build from today.

Ah, excellent: it must have just been a problem with beta 2.  I've just tried with a current nightly and it's working fine.  Don't mind me.  (I wonder what changed...)

Comment 202

[Alex Faaborg [:faaborg] (Firefox UX)]

>the star menu bookmarks tree view could need some color 

Here is a mockup showing some potential ways we can style this type of interface on OS X.  The mockup shows the identity information of the site, but the same styling will also apply to the new bookmark UI. We are calling these things contextual dialogs, kind of like a contextual menu, in that the UI is attached to something, but unlike a menu it contains information and widgets like a dialog box.  Since the UI pattern is mixed, it's a little ambiguous how these things should be styled (menu? dialog? HUD?)

To keep this bug on topic, please provide feedback over in the comments of bug 403158

http://people.mozilla.com/~faaborg/files/granParadisoUI/osxContextualDialogStyle_i1.png

Comment 203

[Aronnax]

Hi,
i think only the Menu or Dialog Box style makes here sense and 
i would prefer the Dialog Box style.

Other elements like buttons and drop-down lists ... are generally only on a darker background and after i played a little bit with the new bookmark UI (Comment #198) have i more and more the impression that the look and feel is  "wrong" on a white (Menu) background.   

by the way, 
Bug 391984 – [10.5] Add roundness to context menus 
has not anymore a blocker status

it concerns as well these elements as far as i see and it would be an extremely good idea to change the status back ;-) 

Cheers 

Comment 204

[Federico B P]

Apple recently updated it's Human Interface Guidelines.
http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIntro/chapter_1_section_1.html

There is also a list of System-Provided Images that developers can use directly:
http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIcons/chapter_15_section_10.html#//apple_ref/doc/uid/20000967-SW15

Comment 206

[Kevin Gerich]

Attachment: Patch against trunk - v4

New patch! I've also uploaded a new version of Proto to AMO with the tweaks contained in this patch

Comment 207

[Kevin Gerich]

Images to go with patch v4: http://kmgerich.com/archive/temp/397723-4-images.tar.gz

Comment 208

[Erin 'Folletto' Casali]

Attachment: Firefox 3 toolbar buttons spacing vs Safari 3

While I think interesting the new toolbar buttons style (Keyhole still have to land, right?) I might just note that immediately when I've updated Proto I noticed that the buttons are consuming too much screen space.

It might be a minor problem (second to the UI coherence) but I think that's an impression that many could have. :)

Maybe reducing the space between the buttons a little bit and maybe eating a few pixels here and there could help. :)

Comment 209

[Shawn Wilsher :sdwilsh]

The new buttons also seem to be really pixelized on the turns - are those images, or are we using moz-border-radius?

Comment 210

[Phil Ringnalda (:philor)]

Comment on attachment 299580 [details] [diff] [review]
Patch against trunk - v4

>Index: toolkit/themes/pinstripe/global/toolbar.css

>+  border-bottom: 1px solid #40404;

Warning: Expected color but found '#40404'.  Expected color but found '#40404'.  Expected end of value for property but found '#40404'.  Error in parsing value for property 'border-bottom'.  Declaration dropped.
Source File: chrome://global/skin/toolbar.css
Line: 58

Comment 211

[Hank Mills]

With all the rounded buttons, it makes the search and location bars feel slightly lopsided since they are only grey on one end. 

Comment 212

[Kevin Gerich]

Attachment: Patch v4 with a few CSS typos fixed

Comment 213

[Mike Connor [:mconnor]]

Comment on attachment 299619 [details] [diff] [review]
Patch v4 with a few CSS typos fixed

r=me, let's land this bad boy

Comment 214

[Phil Ringnalda (:philor)]

Comment on attachment 299619 [details] [diff] [review]
Patch v4 with a few CSS typos fixed

>Index: browser/themes/pinstripe/browser/preferences/applications.css

>+row > vbox {
>+  -moz-box-flex: -1;
>+}

http://mxr.mozilla.org/seamonkey/source/layout/style/nsCSSParser.cpp#4709 is pretty Positive you don't want that.

Comment 215

[Phil Ringnalda (:philor)]

Comment on attachment 299619 [details] [diff] [review]
Patch v4 with a few CSS typos fixed

Sigh. Bugzilla, you idiot, what would make you think changing review flags without a midair warning would be a good idea?

Comment 216

[Kevin Gerich]

Landed, after fixing issues that Phil pointed out. Thanks Phil.

Checking in browser/themes/pinstripe/browser/Go-arrow.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/Go-arrow.png,v  <--  Go-arrow.png
new revision: 1.2; previous revision: 1.1
done
Checking in browser/themes/pinstripe/browser/Search-bar.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/Search-bar.png,v  <--  Search-bar.png
new revision: 1.3; previous revision: 1.2
done
Checking in browser/themes/pinstripe/browser/Search.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/Search.png,v  <--  Search.png
new revision: 1.3; previous revision: 1.2
done
Checking in browser/themes/pinstripe/browser/Toolbar.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/Toolbar.png,v  <--  Toolbar.png
new revision: 1.7; previous revision: 1.6
done
Checking in browser/themes/pinstripe/browser/bookmark-open-left.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/bookmark-open-left.png,v  <--  bookmark-open-left.png
new revision: 1.4; previous revision: 1.3
done
Checking in browser/themes/pinstripe/browser/bookmark-open-mid.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/bookmark-open-mid.png,v  <--  bookmark-open-mid.png
new revision: 1.4; previous revision: 1.3
done
Checking in browser/themes/pinstripe/browser/bookmark-open-right.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/bookmark-open-right.png,v  <--  bookmark-open-right.png
new revision: 1.5; previous revision: 1.4
done
Checking in browser/themes/pinstripe/browser/bookmark_toolbar_background.gif;
/cvsroot/mozilla/browser/themes/pinstripe/browser/bookmark_toolbar_background.gif,v  <--  bookmark_toolbar_background.gif
new revision: 1.4; previous revision: 1.3
done
Checking in browser/themes/pinstripe/browser/browser.css;
/cvsroot/mozilla/browser/themes/pinstripe/browser/browser.css,v  <--  browser.css
new revision: 1.109; previous revision: 1.108
done
Checking in browser/themes/pinstripe/browser/browser.xml;
/cvsroot/mozilla/browser/themes/pinstripe/browser/browser.xml,v  <--  browser.xml
new revision: 1.5; previous revision: 1.4
done
Checking in browser/themes/pinstripe/browser/icon.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/icon.png,v  <--  icon.png
new revision: 1.4; previous revision: 1.3
done
Checking in browser/themes/pinstripe/browser/jar.mn;
/cvsroot/mozilla/browser/themes/pinstripe/browser/jar.mn,v  <--  jar.mn
new revision: 1.67; previous revision: 1.66
done
Checking in browser/themes/pinstripe/browser/page-livemarks.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/page-livemarks.png,v  <--  page-livemarks.png
new revision: 1.4; previous revision: 1.3
done
Checking in browser/themes/pinstripe/browser/pageInfo.css;
/cvsroot/mozilla/browser/themes/pinstripe/browser/pageInfo.css,v  <--  pageInfo.css
new revision: 1.12; previous revision: 1.11
done
RCS file: /cvsroot/mozilla/browser/themes/pinstripe/browser/radio-selected-bg.gif,v
done
Checking in browser/themes/pinstripe/browser/radio-selected-bg.gif;
/cvsroot/mozilla/browser/themes/pinstripe/browser/radio-selected-bg.gif,v  <--  radio-selected-bg.gif
initial revision: 1.1
done
Checking in browser/themes/pinstripe/browser/search-bar-background-mid.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/search-bar-background-mid.png,v  <--  search-bar-background-mid.png
new revision: 1.3; previous revision: 1.2
done
Checking in browser/themes/pinstripe/browser/searchbar.css;
/cvsroot/mozilla/browser/themes/pinstripe/browser/searchbar.css,v  <--  searchbar.css
new revision: 1.19; previous revision: 1.18
done
Checking in browser/themes/pinstripe/browser/wrench.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/wrench.png,v  <--  wrench.png
new revision: 1.3; previous revision: 1.2
done
Checking in browser/themes/pinstripe/browser/bookmarks/bookmark-folder.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/bookmarks/bookmark-folder.png,v  <--  bookmark-folder.png
new revision: 1.3; previous revision: 1.2
done
Checking in browser/themes/pinstripe/browser/bookmarks/bookmark-item.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/bookmarks/bookmark-item.png,v  <--  bookmark-item.png
new revision: 1.3; previous revision: 1.2
done
Checking in browser/themes/pinstripe/browser/bookmarks/folderarrow.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/bookmarks/folderarrow.png,v  <--  folderarrow.png
new revision: 1.4; previous revision: 1.3
done
RCS file: /cvsroot/mozilla/browser/themes/pinstripe/browser/places/contentSplitter-bg.gif,v
done
Checking in browser/themes/pinstripe/browser/places/contentSplitter-bg.gif;
/cvsroot/mozilla/browser/themes/pinstripe/browser/places/contentSplitter-bg.gif,v  <--  contentSplitter-bg.gif
initial revision: 1.1
done
Checking in browser/themes/pinstripe/browser/places/folderDropArrow.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/places/folderDropArrow.png,v  <--  folderDropArrow.png
new revision: 1.2; previous revision: 1.1
done
RCS file: /cvsroot/mozilla/browser/themes/pinstripe/browser/places/infoPaneGrippy.png,v
done
Checking in browser/themes/pinstripe/browser/places/infoPaneGrippy.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/places/infoPaneGrippy.png,v  <--  infoPaneGrippy.png
initial revision: 1.1
done
Checking in browser/themes/pinstripe/browser/places/livemarkFolder.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/places/livemarkFolder.png,v  <--  livemarkFolder.png
new revision: 1.2; previous revision: 1.1
done
Checking in browser/themes/pinstripe/browser/places/livemarkItem.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/places/livemarkItem.png,v  <--  livemarkItem.png
new revision: 1.3; previous revision: 1.2
done
RCS file: /cvsroot/mozilla/browser/themes/pinstripe/browser/places/menubutton-end.png,v
done
Checking in browser/themes/pinstripe/browser/places/menubutton-end.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/places/menubutton-end.png,v  <--  menubutton-end.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/browser/themes/pinstripe/browser/places/menubutton-mid.png,v
done
Checking in browser/themes/pinstripe/browser/places/menubutton-mid.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/places/menubutton-mid.png,v  <--  menubutton-mid.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/browser/themes/pinstripe/browser/places/menubutton-start.png,v
done
Checking in browser/themes/pinstripe/browser/places/menubutton-start.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/places/menubutton-start.png,v  <--  menubutton-start.png
initial revision: 1.1
done
Checking in browser/themes/pinstripe/browser/places/organizer.css;
/cvsroot/mozilla/browser/themes/pinstripe/browser/places/organizer.css,v  <--  organizer.css
new revision: 1.2; previous revision: 1.1
done
Checking in browser/themes/pinstripe/browser/places/pageStarred.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/places/pageStarred.png,v  <--  pageStarred.png
new revision: 1.2; previous revision: 1.1
done
Checking in browser/themes/pinstripe/browser/places/places.css;
/cvsroot/mozilla/browser/themes/pinstripe/browser/places/places.css,v  <--  places.css
new revision: 1.20; previous revision: 1.19
done
Checking in browser/themes/pinstripe/browser/places/query.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/places/query.png,v  <--  query.png
new revision: 1.3; previous revision: 1.2
done
RCS file: /cvsroot/mozilla/browser/themes/pinstripe/browser/places/selected-focused-gradient.png,v
done
Checking in browser/themes/pinstripe/browser/places/selected-focused-gradient.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/places/selected-focused-gradient.png,v  <--  selected-focused-gradient.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/browser/themes/pinstripe/browser/places/selected-gradient.png,v
done
Checking in browser/themes/pinstripe/browser/places/selected-gradient.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/places/selected-gradient.png,v  <--  selected-gradient.png
initial revision: 1.1
done
Checking in browser/themes/pinstripe/browser/places/starPage.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/places/starPage.png,v  <--  starPage.png
new revision: 1.3; previous revision: 1.2
done
Checking in browser/themes/pinstripe/browser/preferences/Options.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/preferences/Options.png,v  <--  Options.png
new revision: 1.9; previous revision: 1.8
done
Checking in browser/themes/pinstripe/browser/preferences/preferences.css;
/cvsroot/mozilla/browser/themes/pinstripe/browser/preferences/preferences.css,v  <--  preferences.css
new revision: 1.24; previous revision: 1.23
done
Checking in browser/themes/pinstripe/browser/tabbrowser/alltabs-box-bkgnd.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/tabbrowser/alltabs-box-bkgnd.png,v  <--  alltabs-box-bkgnd.png
new revision: 1.3; previous revision: 1.2
done
Checking in browser/themes/pinstripe/browser/tabbrowser/tab-arrow-end-bkgnd.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/tabbrowser/tab-arrow-end-bkgnd.png,v  <--  tab-arrow-end-bkgnd.png
new revision: 1.3; previous revision: 1.2
done
Checking in browser/themes/pinstripe/browser/tabbrowser/tab-arrow-end.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/tabbrowser/tab-arrow-end.png,v  <--  tab-arrow-end.png
new revision: 1.3; previous revision: 1.2
done
Checking in browser/themes/pinstripe/browser/tabbrowser/tab-arrow-start-bkgnd.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/tabbrowser/tab-arrow-start-bkgnd.png,v  <--  tab-arrow-start-bkgnd.png
new revision: 1.2; previous revision: 1.1
done
Checking in browser/themes/pinstripe/browser/tabbrowser/tab-arrow-start.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/tabbrowser/tab-arrow-start.png,v  <--  tab-arrow-start.png
new revision: 1.3; previous revision: 1.2
done
Checking in browser/themes/pinstripe/browser/tabbrowser/tab-left-bkgnd.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/tabbrowser/tab-left-bkgnd.png,v  <--  tab-left-bkgnd.png
new revision: 1.3; previous revision: 1.2
done
Checking in browser/themes/pinstripe/browser/tabbrowser/tab-left.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/tabbrowser/tab-left.png,v  <--  tab-left.png
new revision: 1.3; previous revision: 1.2
done
Checking in browser/themes/pinstripe/browser/tabbrowser/tab-middle-bkgnd.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/tabbrowser/tab-middle-bkgnd.png,v  <--  tab-middle-bkgnd.png
new revision: 1.3; previous revision: 1.2
done
Checking in browser/themes/pinstripe/browser/tabbrowser/tab-middle.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/tabbrowser/tab-middle.png,v  <--  tab-middle.png
new revision: 1.3; previous revision: 1.2
done
Checking in browser/themes/pinstripe/browser/tabbrowser/tab-right-bkgnd.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/tabbrowser/tab-right-bkgnd.png,v  <--  tab-right-bkgnd.png
new revision: 1.3; previous revision: 1.2
done
Checking in browser/themes/pinstripe/browser/tabbrowser/tab-right.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/tabbrowser/tab-right.png,v  <--  tab-right.png
new revision: 1.3; previous revision: 1.2
done
Checking in browser/themes/pinstripe/browser/tabbrowser/tabbrowser-tabs-bkgnd.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/tabbrowser/tabbrowser-tabs-bkgnd.png,v  <--  tabbrowser-tabs-bkgnd.png
new revision: 1.3; previous revision: 1.2
done
RCS file: /cvsroot/mozilla/browser/themes/pinstripe/browser/urlbar/endcap-secure.png,v
done
Checking in browser/themes/pinstripe/browser/urlbar/endcap-secure.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/urlbar/endcap-secure.png,v  <--  endcap-secure.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/browser/themes/pinstripe/browser/urlbar/endcap.png,v
done
Checking in browser/themes/pinstripe/browser/urlbar/endcap.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/urlbar/endcap.png,v  <--  endcap.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/browser/themes/pinstripe/browser/urlbar/startcap-active.png,v
done
Checking in browser/themes/pinstripe/browser/urlbar/startcap-active.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/urlbar/startcap-active.png,v  <--  startcap-active.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/browser/themes/pinstripe/browser/urlbar/startcap-secure-active.png,v
done
Checking in browser/themes/pinstripe/browser/urlbar/startcap-secure-active.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/urlbar/startcap-secure-active.png,v  <--  startcap-secure-active.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/browser/themes/pinstripe/browser/urlbar/startcap-secure.png,v
done
Checking in browser/themes/pinstripe/browser/urlbar/startcap-secure.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/urlbar/startcap-secure.png,v  <--  startcap-secure.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/browser/themes/pinstripe/browser/urlbar/startcap-verified-end.png,v
done
Checking in browser/themes/pinstripe/browser/urlbar/startcap-verified-end.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/urlbar/startcap-verified-end.png,v  <--  startcap-verified-end.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/browser/themes/pinstripe/browser/urlbar/startcap-verified-mid.png,v
done
Checking in browser/themes/pinstripe/browser/urlbar/startcap-verified-mid.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/urlbar/startcap-verified-mid.png,v  <--  startcap-verified-mid.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/browser/themes/pinstripe/browser/urlbar/startcap-verified-start.png,v
done
Checking in browser/themes/pinstripe/browser/urlbar/startcap-verified-start.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/urlbar/startcap-verified-start.png,v  <--  startcap-verified-start.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/browser/themes/pinstripe/browser/urlbar/startcap.png,v
done
Checking in browser/themes/pinstripe/browser/urlbar/startcap.png;
/cvsroot/mozilla/browser/themes/pinstripe/browser/urlbar/startcap.png,v  <--  startcap.png
initial revision: 1.1
done
Checking in toolkit/themes/pinstripe/global/findBar.css;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/findBar.css,v  <--  findBar.css
new revision: 1.8; previous revision: 1.7
done
Checking in toolkit/themes/pinstripe/global/global.css;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/global.css,v  <--  global.css
new revision: 1.19; previous revision: 1.18
done
Checking in toolkit/themes/pinstripe/global/globalBindings.xml;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/globalBindings.xml,v  <--  globalBindings.xml
new revision: 1.24; previous revision: 1.23
done
Checking in toolkit/themes/pinstripe/global/jar.mn;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/jar.mn,v  <--  jar.mn
new revision: 1.38; previous revision: 1.37
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/statusbar-background.gif,v
done
Checking in toolkit/themes/pinstripe/global/statusbar-background.gif;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/statusbar-background.gif,v  <--  statusbar-background.gif
initial revision: 1.1
done
Checking in toolkit/themes/pinstripe/global/textbox.css;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/textbox.css,v  <--  textbox.css
new revision: 1.7; previous revision: 1.6
done
Checking in toolkit/themes/pinstripe/global/toolbar.css;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/toolbar.css,v  <--  toolbar.css
new revision: 1.14; previous revision: 1.13
done
Checking in toolkit/themes/pinstripe/global/console/console.css;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/console/console.css,v  <--  console.css
new revision: 1.11; previous revision: 1.10
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/checkbox.png,v
done
Checking in toolkit/themes/pinstripe/global/icons/checkbox.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/checkbox.png,v  <--  checkbox.png
initial revision: 1.1
done
Checking in toolkit/themes/pinstripe/global/icons/closetab-active.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/closetab-active.png,v  <--  closetab-active.png
new revision: 1.4; previous revision: 1.3
done
Checking in toolkit/themes/pinstripe/global/icons/closetab.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/closetab.png,v  <--  closetab.png
new revision: 1.4; previous revision: 1.3
done
Checking in toolkit/themes/pinstripe/global/icons/find-bar-background.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/find-bar-background.png,v  <--  find-bar-background.png
new revision: 1.3; previous revision: 1.2
done
Checking in toolkit/themes/pinstripe/global/icons/find-bar-flash.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/find-bar-flash.png,v  <--  find-bar-flash.png
new revision: 1.3; previous revision: 1.2
done
Checking in toolkit/themes/pinstripe/global/icons/find-bar-notfound.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/find-bar-notfound.png,v  <--  find-bar-notfound.png
new revision: 1.3; previous revision: 1.2
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/highlight-active-leftcap.png,v
done
Checking in toolkit/themes/pinstripe/global/icons/highlight-active-leftcap.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/highlight-active-leftcap.png,v  <--  highlight-active-leftcap.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/highlight-active-right.png,v
done
Checking in toolkit/themes/pinstripe/global/icons/highlight-active-right.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/highlight-active-right.png,v  <--  highlight-active-right.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/loading_16.png,v
done
Checking in toolkit/themes/pinstripe/global/icons/loading_16.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/loading_16.png,v  <--  loading_16.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-active-dropmarker.png,v
done
Checking in toolkit/themes/pinstripe/global/icons/round-button-active-dropmarker.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-active-dropmarker.png,v  <--  round-button-active-dropmarker.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-active-left.png,v
done
Checking in toolkit/themes/pinstripe/global/icons/round-button-active-left.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-active-left.png,v  <--  round-button-active-left.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-active-leftcap.png,v
done
Checking in toolkit/themes/pinstripe/global/icons/round-button-active-leftcap.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-active-leftcap.png,v  <--  round-button-active-leftcap.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-active-middle.png,v
done
Checking in toolkit/themes/pinstripe/global/icons/round-button-active-middle.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-active-middle.png,v  <--  round-button-active-middle.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-active-right.png,v
done
Checking in toolkit/themes/pinstripe/global/icons/round-button-active-right.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-active-right.png,v  <--  round-button-active-right.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-dropmarker.png,v
done
Checking in toolkit/themes/pinstripe/global/icons/round-button-dropmarker.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-dropmarker.png,v  <--  round-button-dropmarker.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-left.png,v
done
Checking in toolkit/themes/pinstripe/global/icons/round-button-left.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-left.png,v  <--  round-button-left.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-leftcap.png,v
done
Checking in toolkit/themes/pinstripe/global/icons/round-button-leftcap.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-leftcap.png,v  <--  round-button-leftcap.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-middle.png,v
done
Checking in toolkit/themes/pinstripe/global/icons/round-button-middle.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-middle.png,v  <--  round-button-middle.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-right.png,v
done
Checking in toolkit/themes/pinstripe/global/icons/round-button-right.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/round-button-right.png,v  <--  round-button-right.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/search-textbox.png,v
done
Checking in toolkit/themes/pinstripe/global/icons/search-textbox.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/search-textbox.png,v  <--  search-textbox.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/white-checkbox-active.png,v
done
Checking in toolkit/themes/pinstripe/global/icons/white-checkbox-active.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/white-checkbox-active.png,v  <--  white-checkbox-active.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/white-checkbox-checked.png,v
done
Checking in toolkit/themes/pinstripe/global/icons/white-checkbox-checked.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/white-checkbox-checked.png,v  <--  white-checkbox-checked.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/white-checkbox.png,v
done
Checking in toolkit/themes/pinstripe/global/icons/white-checkbox.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/white-checkbox.png,v  <--  white-checkbox.png
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/white-gray-gradient-active.gif,v
done
Checking in toolkit/themes/pinstripe/global/icons/white-gray-gradient-active.gif;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/white-gray-gradient-active.gif,v  <--  white-gray-gradient-active.gif
initial revision: 1.1
done
Checking in toolkit/themes/pinstripe/global/icons/white-gray-gradient.gif;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/icons/white-gray-gradient.gif,v  <--  white-gray-gradient.gif
new revision: 1.3; previous revision: 1.2
done
Checking in toolkit/themes/pinstripe/global/splitter/dimple.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/splitter/dimple.png,v  <--  dimple.png
new revision: 1.3; previous revision: 1.2
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/toolbar/toolbar-background-tall.gif,v
done
Checking in toolkit/themes/pinstripe/global/toolbar/toolbar-background-tall.gif;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/toolbar/toolbar-background-tall.gif,v  <--  toolbar-background-tall.gif
initial revision: 1.1
done
Checking in toolkit/themes/pinstripe/global/toolbar/toolbar-background.gif;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/toolbar/toolbar-background.gif,v  <--  toolbar-background.gif
new revision: 1.3; previous revision: 1.2
done
Checking in toolkit/themes/pinstripe/global/tree/folder.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/tree/folder.png,v  <--  folder.png
new revision: 1.3; previous revision: 1.2
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/global/tree/item-grayscale.png,v
done
Checking in toolkit/themes/pinstripe/global/tree/item-grayscale.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/tree/item-grayscale.png,v  <--  item-grayscale.png
initial revision: 1.1
done
Checking in toolkit/themes/pinstripe/global/tree/item.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/global/tree/item.png,v  <--  item.png
new revision: 1.3; previous revision: 1.2
done
Checking in toolkit/themes/pinstripe/mozapps/jar.mn;
/cvsroot/mozilla/toolkit/themes/pinstripe/mozapps/jar.mn,v  <--  jar.mn
new revision: 1.24; previous revision: 1.23
done
Checking in toolkit/themes/pinstripe/mozapps/downloads/buttons.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/mozapps/downloads/buttons.png,v  <--  buttons.png
new revision: 1.3; previous revision: 1.2
done
Checking in toolkit/themes/pinstripe/mozapps/downloads/downloadIcon.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/mozapps/downloads/downloadIcon.png,v  <--  downloadIcon.png
new revision: 1.2; previous revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/mozapps/downloads/downloadStatusIcon.png,v
done
Checking in toolkit/themes/pinstripe/mozapps/downloads/downloadStatusIcon.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/mozapps/downloads/downloadStatusIcon.png,v  <--  downloadStatusIcon.png
initial revision: 1.1
done
Checking in toolkit/themes/pinstripe/mozapps/downloads/downloads.css;
/cvsroot/mozilla/toolkit/themes/pinstripe/mozapps/downloads/downloads.css,v  <--  downloads.css
new revision: 1.23; previous revision: 1.22
done
Checking in toolkit/themes/pinstripe/mozapps/extensions/extensionItem.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/mozapps/extensions/extensionItem.png,v  <--  extensionItem.png
new revision: 1.4; previous revision: 1.3
done
Checking in toolkit/themes/pinstripe/mozapps/extensions/extensions.css;
/cvsroot/mozilla/toolkit/themes/pinstripe/mozapps/extensions/extensions.css,v  <--  extensions.css
new revision: 1.33; previous revision: 1.32
done
RCS file: /cvsroot/mozilla/toolkit/themes/pinstripe/mozapps/extensions/extensions.xml,v
done
Checking in toolkit/themes/pinstripe/mozapps/extensions/extensions.xml;
/cvsroot/mozilla/toolkit/themes/pinstripe/mozapps/extensions/extensions.xml,v  <--  extensions.xml
initial revision: 1.1
done
Checking in toolkit/themes/pinstripe/mozapps/extensions/itemDisabledFader.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/mozapps/extensions/itemDisabledFader.png,v  <--  itemDisabledFader.png
new revision: 1.2; previous revision: 1.1
done
Checking in toolkit/themes/pinstripe/mozapps/extensions/notifyBadges.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/mozapps/extensions/notifyBadges.png,v  <--  notifyBadges.png
new revision: 1.3; previous revision: 1.2
done
Checking in toolkit/themes/pinstripe/mozapps/places/defaultFavicon.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/mozapps/places/defaultFavicon.png,v  <--  defaultFavicon.png
new revision: 1.2; previous revision: 1.1
done
Checking in toolkit/themes/pinstripe/mozapps/xpinstall/xpinstallItemGeneric.png;
/cvsroot/mozilla/toolkit/themes/pinstripe/mozapps/xpinstall/xpinstallItemGeneric.png,v  <--  xpinstallItemGeneric.png
new revision: 1.4; previous revision: 1.3
done

Comment 217

[Alex Faaborg [:faaborg] (Firefox UX)]

We don't have to worry about this for landing proto, but at some point we need to update it to support RTL keyhole, similar to what we are doing over in bug 411725, in particular note this attachment: https://bugzilla.mozilla.org/attachment.cgi?id=298693

Comment 218

[jrblier]

Attachment: Various display bugs screen capture with 3b2

I've just tried out the new version of Proto from AMO. I'm using Firefox 3.0b2. Do I need to use trunk or wait for beta 3?

With Proto, the left part of the location bar looks bad with HTTP. With HTTPS it looks fine.

I would like to see the keyhole Back and Forward buttons. So I did look at the Personalize toolbar, which you can see in the attachment. But I guess the keyhole button format is not available yet.

A side issue, the awesome URL bar add a space inside found words at the cursor location. In the URL I type: "plan|" ("|" = cursor) the results shows "http://plan et.mozilla.org.

Comment 219

[Stephen Donner [:stephend] Not actively reading bugmail]

On today's trunk (10.4), with "Show: Icons and Text" chosen in the Customize... dialog, there is _serious_ Back-button jumping going on; doesn't affect the Forward button.

Comment 220

[Kevin Gerich]

(In reply to comment #219)
> On today's trunk (10.4), with "Show: Icons and Text" chosen in the Customize...
> dialog, there is _serious_ Back-button jumping going on; doesn't affect the
> Forward button.
> 

Ack. Please file a bug on this. 

Comment 221

[Mikhail Kashkin]

Attachment: variouse ui glitches with proto 0.10.1

I'm just update Proto theme to 0.10.1 and find new UI glitches on my Mac (10.4.11, MacBook Core 2 Duo).

First I can see on every non https pages in address bar, second icon for downloaded items in download manager.

Comment 222

[Kevin Gerich]

I would appreciate it if those of you with issues would file separate bugs and mark them as blocking this tracking bug. Please note that Proto is obsolete now that the new default theme has landed. Only file bugs against the default theme.

It would also be a big help to list the extensions you have installed when you file bugs, since I'm sure some extensions will break the theme in interesting ways.

Thanks!

Comment 223

[Mikhail Kashkin]

Kevin, I can fill new bug report.

What I have:
Adblock 0.7.5.3
Dom Inspector 1.9b2
Nightly Tester Tools 1.3b4
NoScript 1.3.1
Personas for Firefox 0.9.2
Russian spell dictionary 0.1
ScrapBook 1.3.2.6
SearchStatus 1.22
Weave 0.1.16

Theme Proto
 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2

Comment 224

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #220)
> (In reply to comment #219)
> > On today's trunk (10.4), with "Show: Icons and Text" chosen in the Customize...
> > dialog, there is _serious_ Back-button jumping going on; doesn't affect the
> > Forward button.
> > 
> 
> Ack. Please file a bug on this. 

I spun-off bug 414419.

Comment 225

[Alex Faaborg [:faaborg] (Firefox UX)]

Just a heads up that the keyhole implementation on windows is coming along in bug 411725, if you want to start port it over to proto for beta 3.

Comment 226

[is+mozilla]

I apologize if this a dumb question, but I haven't been able to figure out what exactly are the criteria for "depends on" and "blocks." Should this bug depend on bug 364536 (make mac theme RTL compatible, marked wanted-firefox3)? 

Comment 227

[Asa Dotzler [:asa]]

Should I be filing bugs for missing icons? For example, the "report a broken website" button icon, and the tab d&d dropmarker icon, have not been updated.

Comment 228

[Alex Faaborg [:faaborg] (Firefox UX)]

>Should I be filing bugs for missing icons? For example, the "report a broken
>website" button icon, and the tab d&d dropmarker icon, have not been updated.

I'm closely tracking which icons still need to be refreshed, no need to file individual bugs.

Comment 229

[Mike Beltzner [:beltzner, not reading bugmail]]

This has landed, so I'm dropping it off the Beta 3 blocker list. I will actually swing back around and start marking individual bugs as blockers, as blocking on a tracking bug is a recipe for failure.

(Also, any new bugs should be put in the new Firefox::Theme component)

Comment 230

[Jesse Ruderman]

Better yet, let's mark this as FIXED, since it is fixed.  Please continue to mark bugs in the theme as blocking this bug.

Comment 231

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

The new theme was successfully landed with beta 3. Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3 ID:2008020511.

This doesn't effect the remaining blocking bugs...