947346 - UI regression for toolbox toolbars and tabs on Windows since bug 941673

Status: VERIFIED FIXED

(DevTools :: Framework, defect)

Description

[Girish Sharma [:Optimizer]]

Attachment: windows.jpg

Since osx and windows styles were merged. Osx's styles were forced onto Windows. While in terms of colors they might be similar for most cases, there are a lot of things different in the defaults of windows and osx and also other minor stuff.

See the screenshot which lists out most of them.

Comment 1

[Girish Sharma [:Optimizer]]

Attachment: one more diff

One more difference in style editor. See the new and import buttons

Comment 2

[Brian Grinstead [:bgrins]]

(In reply to Girish Sharma [:Optimizer] from comment #0)
> Created attachment 8343870 [details]
> windows.jpg
> 
> Since osx and windows styles were merged. Osx's styles were forced onto
> Windows. While in terms of colors they might be similar for most cases,
> there are a lot of things different in the defaults of windows and osx and
> also other minor stuff.
> 
> See the screenshot which lists out most of them.

FWIW, it was mostly Linux styles that were copied onto Windows, not OSX.  Thanks for taking the screenshot and listing out the issues.  We should be able to handle platform specific issues with preprocessor directives when needed, but I would hope that we can avoid these as much as possible.  Things like this weird outline on dock to side and the splitter color should definitely be resolved.

Generally, how important are the things like the rounded input and gradient for selected buttons, beyond personal preference?  I think with the new theme, we are targeting a consistent style rather than different depending on the OS - but maybe not.

Comment 3

[Girish Sharma [:Optimizer]]

(In reply to Brian Grinstead [:bgrins] from comment #2)
> FWIW, it was mostly Linux styles that were copied onto Windows, not OSX. 
> Thanks for taking the screenshot and listing out the issues.  We should be
> able to handle platform specific issues with preprocessor directives when
> needed, but I would hope that we can avoid these as much as possible. 
> Things like this weird outline on dock to side and the splitter color should
> definitely be resolved.
> 
> Generally, how important are the things like the rounded input and gradient

It is exactly like using a square input box on osx. Odd one out. not even a single input box in firefox has rounded borders like that for Windows. Also, rounded borders are only on osx. So this will be inconsistent input boxes design for both windows and linux.

> for selected buttons, beyond personal preference?  I think with the new

For one, we are aiming towards a flatter design. This curved gradient was present only in osx, not even on linux. Doesn't make sense to replace windows and linux with what was on osx.

> theme, we are targeting a consistent style rather than different depending
> on the OS - but maybe not.

Yes, and that consistent should be one step towards the final design, not a step backwards :)

Also, I don't think that we can avoid being platform specific in case of input boxes at least. Just like I hate these out of place rounded boxes on windows, osx users will hate the square boxes :)

Comment 4

[Brian Grinstead [:bgrins]]

(In reply to Girish Sharma [:Optimizer] from comment #3)
> (In reply to Brian Grinstead [:bgrins] from comment #2)
> > FWIW, it was mostly Linux styles that were copied onto Windows, not OSX. 
> > Thanks for taking the screenshot and listing out the issues.  We should be
> > able to handle platform specific issues with preprocessor directives when
> > needed, but I would hope that we can avoid these as much as possible. 
> > Things like this weird outline on dock to side and the splitter color should
> > definitely be resolved.
> > 
> > Generally, how important are the things like the rounded input and gradient
> 
> It is exactly like using a square input box on osx. Odd one out. not even a
> single input box in firefox has rounded borders like that for Windows. Also,
> rounded borders are only on osx. So this will be inconsistent input boxes
> design for both windows and linux.
> 

Fair enough - we can add rounded corners only in the case for OSX.

> > for selected buttons, beyond personal preference?  I think with the new
> 
> For one, we are aiming towards a flatter design. This curved gradient was
> present only in osx, not even on linux. Doesn't make sense to replace
> windows and linux with what was on osx.
> 

Yes, we are aiming towards a flatter design, but the old Windows one isn't matching the new themes, either.  Also, the rest of the toolbars aren't updated yet (look at things like the breadcrumbs and inspect element button).  I opened Bug 942292 for updating the toolbar styles based on the new designs.

Regarding the changes to make it look better on Windows, are you able to help with this?  I can do it, but it will be slow, since I need to push to try to check changes.  Plus you will have a better idea of what things should look like.  I will attach a patch that at least updates the border radius on inputs, let me know if you want me to track down the other issues.

Comment 5

[Brian Grinstead [:bgrins]]

Attachment: theme-windows.patch

Does this fix the input problem?

Comment 6

[Brian Grinstead [:bgrins]]

Attachment: theme-windows-splitter.patch

Does this fix the white horizontal splitter problem in the original screenshot?  Looking at the diff from https://bugzilla.mozilla.org/attachment.cgi?id=8341091&action=diff this may resolve that issue.

Comment 7

[Tim Nguyen :ntim]

The tabs are also way bigger because if this bug.
The spliter that seperates the rule view and the markup panel in the inspector used to be lighter before the update, now it's all black.
The prettify icon in the debugger isn't properly aligned in the button too.
The command buttons also have the weird border state too.
The breadcrumbs seem to look quite weird too.
Many things are broken anyways.

Comment 8

[Brian Grinstead [:bgrins]]

(In reply to ntim007 from comment #7)
> The tabs are also way bigger because if this bug.
> The spliter that seperates the rule view and the markup panel in the
> inspector used to be lighter before the update, now it's all black.
> The prettify icon in the debugger isn't properly aligned in the button too.
> The command buttons also have the weird border state too.
> The breadcrumbs seem to look quite weird too.
> Many things are broken anyways.

I understand that things don't look the same.  Do not fear - we are going to fix any regressions and make sure it lands in Aurora.  I am considering regressions in this case to be obvious visual glitches or things that break native UI standards.

It is important that we make the distinction between these things and things that just look different now, since we are going through some redesigns in Bug 916766.  Here is the list of things that need to be fixed in this bug from my point of view:

* Rounded corners on text boxes.
* Splitter above devtools has a background color.
* Weird border state on command buttons.
* The prettify icon in the debugger isn't properly aligned in the button

Things that I think should be done elsewhere, or I don't fully understand from the descriptions:

* "The tabs are also way bigger because if this bug."  I'm not seeing this in Optimizer's screenshot.
* "The breadcrumbs seem to look quite weird."  Not sure exactly what this means, but maybe this is an artifact of copying over the Linux styles.  These are going to be updated in Bug 936421 anyway.
* There are now gradients in buttons for style editor and filters for console.  These styles are going to be updated in Bug 942292.
* "Many things are broken anyways."  What else is broken?

Comment 9

[Tim Nguyen :ntim]

The two first problems, I'll share a screenshot.
Other things :
- The splitter in the Variables view is horrible (similar to the top toolbox splitter)
- There seem to be less padding in the console menu button (the toggles) dropdowns.
- The selected toolbox tab icon is no longer "opacity:1" (it can be seen in optimizer's screenshot)

There are many minor differences, but I guess it's gonna be fixed with the new designs.

Comment 10

[Tim Nguyen :ntim]

Oh yeah, forgot, the search boxes no longer have a focus state (they used to have a blue border on focus)

Comment 11

[Tim Nguyen :ntim]

Also, even without the ugly splitters, the toolbox top border and the variables view in debugger are lighter than they used to be, instead of black, they are gray.

Comment 12

[Brian Grinstead [:bgrins]]

> - The selected toolbox tab icon is no longer "opacity:1" (it can be seen in
> optimizer's screenshot)

This is affecting all OSes, and can be fixed with a line in the toolbox.css like this: https://bugzilla.mozilla.org/attachment.cgi?id=8343971&action=diff#a/browser/themes/shared/devtools/toolbars.inc.css_sec2.  We should include this fix in here as well.

Comment 13

[Tim Nguyen :ntim]

A fix for the huge style editor buttons would also be nice. It is shown in optimizers 2nd screen.

Comment 14

[Tim Nguyen :ntim]

In your patch there seem to be a duplicated rule for .devtools-side-splitter, you readded background-color:transparent;

Comment 15

[Brian Grinstead [:bgrins]]

(In reply to Tim Nguyen [:ntim] from comment #14)
> In your patch there seem to be a duplicated rule for
> .devtools-side-splitter, you readded background-color:transparent;

Ah, I see that now.  Are you able to confirm that the patch fixes the problem with the splitter color and the rounded corners on the text boxes?

Comment 16

[Tim Nguyen :ntim]

(In reply to Brian Grinstead [:bgrins] from comment #15)
> (In reply to Tim Nguyen [:ntim] from comment #14)
> > In your patch there seem to be a duplicated rule for
> > .devtools-side-splitter, you readded background-color:transparent;
> 
> Ah, I see that now.  Are you able to confirm that the patch fixes the
> problem with the splitter color and the rounded corners on the text boxes?

Well, in theory it should, but why does the second patch include the first patch ? You should mark the first one as obsolete. 
Anyways, found another bug, the developer toolbar's styling is broken (even in safe mode)

Comment 17

[Tim Nguyen :ntim]

Btw Brian, this is totally unrelated, but how do I get the debugger resumption order panel to be shown (to fix my first bug). To be honest, I never use the debugger. I asked on IRC, but no one answered.

Comment 18

[Brian Grinstead [:bgrins]]

(In reply to Tim Nguyen [:ntim] from comment #17)
> Btw Brian, this is totally unrelated, but how do I get the debugger
> resumption order panel to be shown (to fix my first bug). To be honest, I
> never use the debugger. I asked on IRC, but no one answered.

Tim,
What is the bug number?  If it is a first bug, it should hopefully have a mentor who you can ask in the bug for help.

Comment 19

[Tim Nguyen :ntim]

There's already a mentor (Victor Porof), but I'm just taking advantage of the fact that you're online so I can get an earlier response.
Here's the bug number : bug 947143

Comment 20

[Paul Rouget [:paul]]

(In reply to Tim Nguyen [:ntim] from comment #19)
> There's already a mentor (Victor Porof), but I'm just taking advantage of
> the fact that you're online so I can get an earlier response.
> Here's the bug number : bug 947143

(Please discuss this in the relevant bug or on IRC)

Comment 21

[Paul Rouget [:paul]]

(In reply to Brian Grinstead [:bgrins] from comment #4)
> (In reply to Girish Sharma [:Optimizer] from comment #3)
> > (In reply to Brian Grinstead [:bgrins] from comment #2)
> > > FWIW, it was mostly Linux styles that were copied onto Windows, not OSX. 
> > > Thanks for taking the screenshot and listing out the issues.  We should be
> > > able to handle platform specific issues with preprocessor directives when
> > > needed, but I would hope that we can avoid these as much as possible. 
> > > Things like this weird outline on dock to side and the splitter color should
> > > definitely be resolved.
> > > 
> > > Generally, how important are the things like the rounded input and gradient
> > 
> > It is exactly like using a square input box on osx. Odd one out. not even a
> > single input box in firefox has rounded borders like that for Windows. Also,
> > rounded borders are only on osx. So this will be inconsistent input boxes
> > design for both windows and linux.
> > 
> 
> Fair enough - we can add rounded corners only in the case for OSX.

So,

> not even a single input box in firefox has rounded borders like that for Windows

You can't use this argument :) 90% of the design of the toolbox can't be found on Windows and Mac (black tabs, floating scrollbars, …).

Let's not choose between Windows and Mac, or use preprocessing instructions to get different styles, let's find a design that works for the toolbox across the platforms. We should use as less as possible specific styles (maintenance is hard).

Comment 22

[Girish Sharma [:Optimizer]]

Then I say we go with the (previously) majority case of square input boxes :)

Comment 23

[Paul Rouget [:paul]]

(In reply to Girish Sharma [:Optimizer] from comment #22)
> Then I say we go with the (previously) majority case of square input boxes :)

Why? And how do you count? (majority?) I'll delegate that to UX.

Comment 24

[Paul Rouget [:paul]]

Darrin, halp!, we need a search box design that works across the 3 platforms.

Comment 25

[Girish Sharma [:Optimizer]]

(In reply to Paul Rouget [:paul] from comment #23)
> (In reply to Girish Sharma [:Optimizer] from comment #22)
> > Then I say we go with the (previously) majority case of square input boxes :)
> 
> Why? And how do you count? (majority?) I'll delegate that to UX.

I count by both 2 out of three tiers (Windows and Linux had square border) and majority of users (Windows + Linux make more than 70% of Firefox users)

Comment 26

[Brian Grinstead [:bgrins]]

Attachment: theme-windows-fixes.patch

This should fix the splitter, button hover, and pretty print alignment.  Can you confirm?

Comment 27

[Girish Sharma [:Optimizer]]

Comment on attachment 8344719 [details] [diff] [review]
theme-windows-fixes.patch

Review of attachment 8344719 [details] [diff] [review]:
-----------------------------------------------------------------

See the screenshot [0] . While the button borders on hover are fine. The horizontal splitter is still 1 px white. It should be transparent, as it was previously [1].

Also, the pretty print button is still not aligned. Looks like the rules debugger.css are being overridden by the ones in dark-theme.css
Also, the Style editor's buttons are still weirdly big .


[0] http://i.snag.gy/20VIC.jpg
[1] http://mxr.mozilla.org/mozilla-aurora/source/browser/themes/windows/devtools/common.css#221

Comment 28

[Brian Grinstead [:bgrins]]

(In reply to Girish Sharma [:Optimizer] from comment #27)

> See the screenshot [0] . While the button borders on hover are fine. The
> horizontal splitter is still 1 px white. It should be transparent, as it was
> previously [1].
> 

Hmm, this is the same rule I've added to the patch: https://bugzilla.mozilla.org/attachment.cgi?id=8344719&action=diff#a/browser/themes/shared/devtools/common.css_sec2 versus: http://mxr.mozilla.org/mozilla-aurora/source/browser/themes/windows/devtools/common.css#221.  This seemed to fix it for me when testing with DOM inspector on nightly.

> Also, the pretty print button is still not aligned. Looks like the rules
> debugger.css are being overridden by the ones in dark-theme.css

Weird, setting font-weight: normal seemed to fix it for me when testing with DOM inspector on nightly.  But I can mess around with it some more.

> Also, the Style editor's buttons are still weirdly big.

I see this now - it looks like it's not so much that the buttons are big but that the toolbar they are in is small.

Comment 29

[Victor Porof [:vporof][:vp]]

(In reply to Girish Sharma [:Optimizer] from comment #27)
> Comment on attachment 8344719 [details] [diff] [review]
> theme-windows-fixes.patch
> 
> Review of attachment 8344719 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> See the screenshot [0] . While the button borders on hover are fine. The
> horizontal splitter is still 1 px white. It should be transparent, as it was
> previously [1].
> 

It wasn't previously transparent. It was black.

Comment 30

[Girish Sharma [:Optimizer]]

(In reply to Victor Porof [:vp] from comment #29)
> It wasn't previously transparent. It was black.

Black was the border color. The background color was transparent. See the [1] link in #27

Comment 31

[Paul Rouget [:paul]]

(In reply to Girish Sharma [:Optimizer] from comment #25)
> > Why? And how do you count? (majority?) I'll delegate that to UX.
> 
> I count by both 2 out of three tiers (Windows and Linux had square border)
> and majority of users (Windows + Linux make more than 70% of Firefox users)

You're making the assumption that the devtools users are represented the same way as the firefox users. I don't think it's true. I actually think nothing. I just don't know :)

Comment 32

[Girish Sharma [:Optimizer]]

No, I was not talking about the usage of devtools here. I was pointing to the fact that which type of input boxes will be at home to more users. Nothing to do with devtools. But if we use same style across all os'es why not choose the input boxes style which is at home to more number of users.

Also, if we really want, we can try to figure out the distribution of devtools users via our telemetry results :)

Comment 33

[Girish Sharma [:Optimizer]]

(apparently, either telemetry does not give user os information, or I am unable to figure out the telemetry dashboard that we have)

Comment 34

[Darrin Henein [:darrin]]

Here's my 2 cents: I think as long as we are developing our own UI guidelines within the devtools that don't adhere to the OS guidelines (our dark flat theme, top tab bar, etc. as Paul mentioned above) I think an input box which is consistent with *our* devtools UI is more important than trying to tweak individual pieces of our UI to resemble the OS chrome. If we can develop and deliver a consistent experience *within* our tools and toolbox, I think the user will have no issues.

Not as a perfect example, but look at Adobe's suite of applications... they appear very similarly/consistently across Windows, OSX, etc. and have their own (instantly recognizable and usable) UI paradigms. We are not the first people to do this.

To answer the original question, I think we universally use the styled, rounded text inputs as they appear in shorlander's mockup.

Comment 35

[Brian Grinstead [:bgrins]]

Attachment: theme-windows-fixes.patch

OK, I believe that I have tracked down the main remaining issues:
* Style editor buttons should be resized and smaller in both width and height now
* Had to use -moz-border-top-colors to get rid of the white border on the horizontal splitter (go figure)
* Pretty print button should be center aligned again - removed margin on  .toolbarbutton-icon

Can you please have a look and see if the issues above are resolved for you?  Note: I've also reverted to the rounded border to match the comps as mentioned in Comment 34.

Comment 36

[Darrin Henein [:darrin]]

So I spent some time yesterday getting a few opinions (esp. from people more familiar with Windows design patterns) and after sleeping on it, I want to change my answer to the rounded inputs question. I think while maintaining a consistent UI across platforms is important for many reasons, as shorlander put it "you have to know when to break the rules" to provide something comfortable to the user. Rounded inputs seem natural only on OSX, and so I would like to keep them rounded there but use the (slightly rounded) square corners on Windows and Linux.

bgrins, I saw you just reverted this change... I hope its not a pain to re-revert it ;)

Comment 37

[Brian Grinstead [:bgrins]]

(In reply to Darrin Henein [:darrin] from comment #36)
> So I spent some time yesterday getting a few opinions (esp. from people more
> familiar with Windows design patterns) and after sleeping on it, I want to
> change my answer to the rounded inputs question. I think while maintaining a
> consistent UI across platforms is important for many reasons, as shorlander
> put it "you have to know when to break the rules" to provide something
> comfortable to the user. Rounded inputs seem natural only on OSX, and so I
> would like to keep them rounded there but use the (slightly rounded) square
> corners on Windows and Linux.
> 
> bgrins, I saw you just reverted this change... I hope its not a pain to
> re-revert it ;)

It's no problem - I will add it back on the next version once I get the ui review on the current patch from Optimizer.

Comment 38

[Girish Sharma [:Optimizer]]

Comment on attachment 8345503 [details] [diff] [review]
theme-windows-fixes.patch

Review of attachment 8345503 [details] [diff] [review]:
-----------------------------------------------------------------

Everything else is fixed and I like the Style Editor well padded buttons now :)

A few things :

 - Even though this might not be a regressions, the tabs toolbar's bottom border color in the new design of the toolbox tabs is lighter now. which makes it look weird (along with the shadow in place) in options panel in the dark theme. (http://snag.gy/QlMNK.jpg)
 - The control buttons (docking button + close button) still have weird border on hover.
 - You can use the following non moz prefixed way to achieve the splitter top border:

border: 1px solid black;
border-width: 1px 0 0;


(or any other color than black, if you want)

Comment 39

[Brian Grinstead [:bgrins]]

Attachment: theme-windows-fixes.patch

I believe this updates the following:

 - Re adds the non-rounded corners on the textboxes
 - The control buttons (docking button + close button) should not have a border anymore
 - Uses non moz prefixed way to achieve the splitter top border

Comment 40

[Brian Grinstead [:bgrins]]

Comment on attachment 8345952 [details] [diff] [review]
theme-windows-fixes.patch

Review of attachment 8345952 [details] [diff] [review]:
-----------------------------------------------------------------

Joe,
Can you review the changes here?  Even though we are awaiting final confirmation that all issues are resolved in Windows, there shouldn't be any more big changes.

Comment 41

[Joe Walker [:jwalker]]

Comment on attachment 8345952 [details] [diff] [review]
theme-windows-fixes.patch

Review of attachment 8345952 [details] [diff] [review]:
-----------------------------------------------------------------

The CSS changes look good to me, I'm going to assume that Optimizer is going to do a UI review, but I'm happy to have a look if he doesn't.

Comment 42

[Girish Sharma [:Optimizer]]

Comment on attachment 8345952 [details] [diff] [review]
theme-windows-fixes.patch

Review of attachment 8345952 [details] [diff] [review]:
-----------------------------------------------------------------

All the regressions are fixed now :)

Although I do noticed an issue which is a regression of the new toolbox tabs design (bug 941579)

See the screenshot[0]. The top blue glow is only 1 px visible. It is actually 1px high, but 1 px is behind the splitter. As per spec [1], 2px should be visible so the height needs to be either 3px, or we should move the splitter 1 px up. But that will make the splitter overlap the content of the page.

This can be done in a followup.

[0] http://i.snag.gy/OY9TV.jpg 
[1] https://people.mozilla.org/~shorlander/mockups/devTools/ux-refresh-2013/[e-mail]

Comment 43

[Brian Grinstead [:bgrins]]

(In reply to Joe Walker [:jwalker] from comment #41)
> The CSS changes look good to me, I'm going to assume that Optimizer is going
> to do a UI review, but I'm happy to have a look if he doesn't.

(In reply to Girish Sharma [:Optimizer] from comment #42)
> All the regressions are fixed now :)

Great, thanks for the reviews!

> Although I do noticed an issue which is a regression of the new toolbox tabs
> design (bug 941579)
> 
> See the screenshot[0]. The top blue glow is only 1 px visible. It is
> actually 1px high, but 1 px is behind the splitter. As per spec [1], 2px
> should be visible so the height needs to be either 3px, or we should move
> the splitter 1 px up. But that will make the splitter overlap the content of
> the page.
> 
> This can be done in a followup.
> 
> [0] http://i.snag.gy/OY9TV.jpg 
> [1]
> https://people.mozilla.org/~shorlander/mockups/devTools/ux-refresh-2013/
> [e-mail]

I agree - let's do this in a follow up.

Comment 44

[Brian Grinstead [:bgrins]]

https://hg.mozilla.org/integration/fx-team/rev/defc9b99115f
https://tbpl.mozilla.org/?tree=Fx-Team&rev=defc9b99115f

Comment 45

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/defc9b99115f

Comment 46

[Tim Nguyen :ntim]

The patch in bug 941673 was landed in Firefox 28, so I guess, this patch should also be in Firefox Aurora 28.

Comment 47

[Brian Grinstead [:bgrins]]

Comment on attachment 8345952 [details] [diff] [review]
theme-windows-fixes.patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 941673
User impact if declined: There will be a few UI regressions in inside of DevTools on Windows in 28.
Testing completed (on m-c, etc.): Been on m/c since 12/12.  The UI fixes have been reviewed.
Risk to taking this patch (and alternatives if risky): This is a CSS-only change limited to DevTools users.
String or IDL/UUID changes made by this patch:

Comment 48

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/5e2fdd0ab731

Comment 49

[u279076]

Girish, please confirm this is working for you now in Firefox 28 and 29.

Comment 50

[Girish Sharma [:Optimizer]]

Yup.