630459 - Tab view should support high contrast mode on Windows

Status: RESOLVED WONTFIX

(Firefox Graveyard :: Panorama, defect, P2)

Description

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

In Tab View we need to check for the use of high contrast mode, and then fall back to only using system colors if it is detected.

Details on Windows theme detection are in bug 426660, and eventually we might be able to use a selector created over in bug 425598.

Comment 1

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

Alternatively, we could just fall back to system colors if the user has a classic windows theme.  This will also give us a native appearance for the classic users.

Comment 2

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

Nominating due to this being an accessibility issue.

Comment 3

[alexander :surkov (:asurkov)]

(In reply to comment #2)
> Nominating due to this being an accessibility issue.

Thumb up. final+ is worth to go. But can we think of assignee?

Comment 4

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

Attachment: High contrast mode in Tab View

Here's a quick screen shot of high contrast mode in Tab View (ignore the fact that it also happens to be in RTL).

Comment 5

[Dietrich Ayala (:dietrich)]

Can someone point to examples of doing this in the codebase already?

Comment 6

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

Ehsan, Dolske or Dao should be able to point you to a good example.

Comment 7

[(no longer active)]

(In reply to comment #6)
> Ehsan, Dolske or Dao should be able to point you to a good example.

Unfortunately, I can't think of one...  :/

Do you know where this support is implemented?  Is it in widget?

Comment 8

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

We used a system metric for default theme to determine the shape of the site identity button in Firefox 3 (curved for default, square for classic).

Comment 9

[Dão Gottwald [:dao]]

http://mxr.mozilla.org/mozilla-central/source/browser/themes/winstripe/browser/browser-aero.css is full of sections targeting different set of themes.

In this case you need to add a -moz-windows-classic section to browser/themes/winstripe/browser/tabview/tabview.css:

@media all and (-moz-windows-classic) {
  #foo {
    background-color: -moz-dialog;
  }
  #bar {
    border-color: ThreeDShadow;
  }
}

Comment 10

[(no longer active)]

(In reply to comment #9)
> http://mxr.mozilla.org/mozilla-central/source/browser/themes/winstripe/browser/browser-aero.css
> is full of sections targeting different set of themes.
> 
> In this case you need to add a -moz-windows-classic section to
> browser/themes/winstripe/browser/tabview/tabview.css:
> 
> @media all and (-moz-windows-classic) {
>   #foo {
>     background-color: -moz-dialog;
>   }
>   #bar {
>     border-color: ThreeDShadow;
>   }
> }

Does -moz-dialog automatically resolve to the right color in high-contrast mode?

Comment 11

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

>Does -moz-dialog automatically resolve to the right color in high-contrast
>mode?

yeah, it just pulls the system color (which will become black with a high contrast theme).

Comment 12

[:Felipe Gomes (needinfo for replies!)]

I don't know if -moz-dialog will be enough for this bug, because this would have to change the current blue background to -moz-dialog in the regular contrast mode too. *Unless we want to do this?)

There are other hardcoded background and text shadow colors which are slight variations of the blue tone (e.g. the background of tab groups and the selection glow) and need some thought if it will be possible to have values for them that are compatible with both regular and high contrast themes.

I think having bug 425598 would be necessary here.

Comment 13

[Dão Gottwald [:dao]]

(In reply to comment #12)
> I don't know if -moz-dialog will be enough for this bug,

No, it won't be enough. The code in comment 9 was example code.

> because this would
> have to change the current blue background to -moz-dialog in the regular
> contrast mode too. *Unless we want to do this?)

This seems appropriate for classic themes.

> There are other hardcoded background and text shadow colors which are slight
> variations of the blue tone (e.g. the background of tab groups and the
> selection glow) and need some thought if it will be possible to have values for
> them that are compatible with both regular and high contrast themes.

rgba() may be used to overlay platform colors and get different shades of the same platform color.

> I think having bug 425598 would be necessary here.

That wouldn't help. You would still need to take different kinds of high contrast themes into account.

Comment 14

[Michael Yoshitaka Erlewine [:mitcho]]

Alex, is this something we could add to awpy to get some attention?

Comment 15

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

>is this something we could add to awpy to get some attention?

sure , I'll add it tomorrow

Comment 16

[Michael Yoshitaka Erlewine [:mitcho]]

[bugspam: betaN -> final] blocker

Comment 17

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

** PRODUCT DRIVERS PLEASE NOTE **

This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons:

 - it was marked as a soft blocking issue without a requirement for beta coverage

Comment 18

[Kevin Hanes]

bugspam

Comment 19

[Tim Taubert [:ttaubert] (inactive)]

bugspam

Comment 20

[Tim Taubert [:ttaubert] (inactive)]

bugspam

Comment 21

[Tim Taubert [:ttaubert] (inactive)]

bugspam

(Fx7 was branched, removing open bugs from Fx7 meta bug, we won't create new meta bugs for upcoming Fx versions)

Comment 22

[Justin Dolske [:Dolske]]

Panorama has been removed from Firefox 45, currently in Beta and scheduled for release on March 7th. As such, I'm closing all existing Panorama bugs.

If you are still using Panorama, you will see a deprecation message in Firefox 44, and when 45 is released your tab group data will be migrated to bookmarks, with a folder for each group. There are also a few addons offering similar functionality.

See https://support.mozilla.org/en-US/kb/tab-groups-removal for more info.

We're removing Panorama because it has extremely low usage (about 0.01% of users), and has a large number of bugs and usability issues. The cost of fixing all those issues is far too high to justify, and so we'll instead be focusing our time and energy on improving other parts of Firefox.