1013913 - Add meta name="theme-color" to have configurable status bar color

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Comment 1

[Kevin Grandon :kgrandon]

We have a crazy hack for doing this in the homescreen that I would like to remove: https://github.com/mozilla-b2g/gaia/commit/637213e32deb42b051acf6e47755518a8baad34c

Comment 2

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: meta.mozstatusbar.patch

Completely untested patch.

Comment 3

[Kevin Grandon :kgrandon]

Not sure if we will be able to get this uplifted, but it would be really nice to have. Dale or Vivien - are either of you two willing to drive this to landing? If you guys are totally busy, I might be able to give this a go - I'm just worried I'm going to be slammed with homescreen blockers.

Comment 4

[Dale Harvey (:daleharvey)]

I am not gonna be able to get this landable today, happy to implement and hope it makes an uplift

Comment 5

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Needinfo'ing Ehsan and Jonas, just to make sure that it is actually something we want to do.

Comment 6

[(no longer active)]

I'm not exactly sure what this patch does, it seems to send messages about mozstatusbar meta tags but I'm not sure what the semantics are, and why it's not header-color as the bug summary suggests...

Comment 7

[Dale Harvey (:daleharvey)]

The intention is for webcontent to be able to specify the color we use for the gaia status bar (and other possible potential places), the name I picked opening the bug was fairly arbitrary, viviens choice was probably better

Chrome have an intent to implement this as well https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/nzRY-h_-_ig/IeXq74xUWzkJ

Comment 8

[(no longer active)]

(In reply to Dale Harvey (:daleharvey) from comment #7)
> The intention is for webcontent to be able to specify the color we use for
> the gaia status bar (and other possible potential places), the name I picked
> opening the bug was fairly arbitrary, viviens choice was probably better
> 
> Chrome have an intent to implement this as well
> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/nzRY-h_-_ig/
> IeXq74xUWzkJ

This is a bit ridiculous.  :(  Can't we work together on a proposal here?  We should not each do our own thing really if everyone agrees that this is a useful feature.

Comment 9

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #8)
> (In reply to Dale Harvey (:daleharvey) from comment #7)
> > The intention is for webcontent to be able to specify the color we use for
> > the gaia status bar (and other possible potential places), the name I picked
> > opening the bug was fairly arbitrary, viviens choice was probably better
> > 
> > Chrome have an intent to implement this as well
> > https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/nzRY-h_-_ig/
> > IeXq74xUWzkJ
> 
> This is a bit ridiculous.  :(  Can't we work together on a proposal here? 
> We should not each do our own thing really if everyone agrees that this is a
> useful feature.

I never heard of this proposal before. As a non-native speaker, naming is really something I don't mind too much about.

Comment 10

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: brandcolor.patch

Here is a patch that use brand-color. Still need to add tests.

Comment 11

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: system.app.changes.patch

How the changes in the system app may looks like. The effect is not very pretty yet, and we need to change the text color relatively to the background color to keep it readable. I have some code for that somewhere.

Comment 12

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

For what it worth the gaia patch to change the statusbar will be tricky to get right. I feel like this bug may track the dom/browser-element/ implementation only or it will never land :)

Comment 13

[Marcos Caceres [:marcosc]]

Any reason this is not a manifest thing? It's not great to add proprietary prefixed things to the platform, even at the "<meta>" level.

Comment 14

[Kevin Grandon :kgrandon]

(In reply to Marcos Caceres [:marcosc] from comment #13)
> Any reason this is not a manifest thing? It's not great to add proprietary
> prefixed things to the platform, even at the "<meta>" level.

It is useful for apps to be able to control this during the usage of the app. In our homescreen example, we want to change the statusbar background as the user scrolls down the page.

Comment 15

[(no longer active)]

(In reply to comment #14)
> (In reply to Marcos Caceres [:marcosc] from comment #13)
> > Any reason this is not a manifest thing? It's not great to add proprietary
> > prefixed things to the platform, even at the "<meta>" level.
> 
> It is useful for apps to be able to control this during the usage of the app.
> In our homescreen example, we want to change the statusbar background as the
> user scrolls down the page.

Also I think that this is something that we're interested in parsing and changing synchronously.

Comment 16

[(no longer active)]

(In reply to comment #9)
> (In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment
> #8)
> > (In reply to Dale Harvey (:daleharvey) from comment #7)
> > > The intention is for webcontent to be able to specify the color we use for
> > > the gaia status bar (and other possible potential places), the name I picked
> > > opening the bug was fairly arbitrary, viviens choice was probably better
> > > 
> > > Chrome have an intent to implement this as well
> > > https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/nzRY-h_-_ig/
> > > IeXq74xUWzkJ
> > 
> > This is a bit ridiculous.  :(  Can't we work together on a proposal here? 
> > We should not each do our own thing really if everyone agrees that this is a
> > useful feature.
> 
> I never heard of this proposal before. As a non-native speaker, naming is
> really something I don't mind too much about.

FWIW it seems hard to say what Blink means here, see the blink-dev thread here: <https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/nzRY-h_-_ig>.  My best effort to decipher that thread suggests that the semantics of this tag won't be clear until they announce what they mean in Google IO next week.  So it may actually be quite different than what we're trying to achieve here.

Comment 17

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #16)
> (In reply to comment #9)
> > (In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment
> > #8)
> > > (In reply to Dale Harvey (:daleharvey) from comment #7)
> > > > The intention is for webcontent to be able to specify the color we use for
> > > > the gaia status bar (and other possible potential places), the name I picked
> > > > opening the bug was fairly arbitrary, viviens choice was probably better
> > > > 
> > > > Chrome have an intent to implement this as well
> > > > https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/nzRY-h_-_ig/
> > > > IeXq74xUWzkJ
> > > 
> > > This is a bit ridiculous.  :(  Can't we work together on a proposal here? 
> > > We should not each do our own thing really if everyone agrees that this is a
> > > useful feature.
> > 
> > I never heard of this proposal before. As a non-native speaker, naming is
> > really something I don't mind too much about.
> 
> FWIW it seems hard to say what Blink means here, see the blink-dev thread
> here:
> <https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/nzRY-h_-
> _ig>.  My best effort to decipher that thread suggests that the semantics of
> this tag won't be clear until they announce what they mean in Google IO next
> week.  So it may actually be quite different than what we're trying to
> achieve here.

Which is fine. There is a bunch of work in the Gaia apps related to this, and I don't think this can be done for the 2.0 timeframe anyway.


For reference the page I looked for is: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/nzRY-h_-_ig/KR3XWn73tDoJ

Comment 18

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #15)
> (In reply to comment #14)
> > (In reply to Marcos Caceres [:marcosc] from comment #13)
> > > Any reason this is not a manifest thing? It's not great to add proprietary
> > > prefixed things to the platform, even at the "<meta>" level.
> > 
> > It is useful for apps to be able to control this during the usage of the app.
> > In our homescreen example, we want to change the statusbar background as the
> > user scrolls down the page.
> 
> Also I think that this is something that we're interested in parsing and
> changing synchronously.

Exactly. For example a single web page webapp may have different header color, depending on the displayed content. The homescreen is one example, where the statusbar is either transparent or black depending on the scrolling state, or even it should be black when some dialog UI is displayed on top of it.

The email app starts with a 'white/grey' UI at first for the configuration page (this colors means 'Settings') and then it goes to an orange like color afterward, etc...

Comment 19

[Marcos Caceres [:marcosc]]

(In reply to Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) from comment #18)
> (In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment
> #15)
> > (In reply to comment #14)
> > > (In reply to Marcos Caceres [:marcosc] from comment #13)
> > > > Any reason this is not a manifest thing? It's not great to add proprietary
> > > > prefixed things to the platform, even at the "<meta>" level.
> > > 
> > > It is useful for apps to be able to control this during the usage of the app.
> > > In our homescreen example, we want to change the statusbar background as the
> > > user scrolls down the page.
> > 
> > Also I think that this is something that we're interested in parsing and
> > changing synchronously.
> 
> Exactly. For example a single web page webapp may have different header
> color, depending on the displayed content. The homescreen is one example,
> where the statusbar is either transparent or black depending on the
> scrolling state, or even it should be black when some dialog UI is displayed
> on top of it.
> 
> The email app starts with a 'white/grey' UI at first for the configuration
> page (this colors means 'Settings') and then it goes to an orange like color
> afterward, etc...

Ok, I see. This still feels like a pretty poor fit tho. Pretty soon you will want to be doing transitions, etc. and you will be needing a styling language. Why not make this a CSS thing? In any case, if you do implement this, please add a "moz-" vendor prefix.

Comment 20

[(no longer active)]

(In reply to comment #19)
> (In reply to Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails,
> needinfo? please) from comment #18)
> > (In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment
> > #15)
> > > (In reply to comment #14)
> > > > (In reply to Marcos Caceres [:marcosc] from comment #13)
> > > > > Any reason this is not a manifest thing? It's not great to add proprietary
> > > > > prefixed things to the platform, even at the "<meta>" level.
> > > > 
> > > > It is useful for apps to be able to control this during the usage of the app.
> > > > In our homescreen example, we want to change the statusbar background as the
> > > > user scrolls down the page.
> > > 
> > > Also I think that this is something that we're interested in parsing and
> > > changing synchronously.
> > 
> > Exactly. For example a single web page webapp may have different header
> > color, depending on the displayed content. The homescreen is one example,
> > where the statusbar is either transparent or black depending on the
> > scrolling state, or even it should be black when some dialog UI is displayed
> > on top of it.
> > 
> > The email app starts with a 'white/grey' UI at first for the configuration
> > page (this colors means 'Settings') and then it goes to an orange like color
> > afterward, etc...
> 
> Ok, I see. This still feels like a pretty poor fit tho. Pretty soon you will
> want to be doing transitions, etc. and you will be needing a styling language.

You mean declaring a transition?  Do we want to do that?  It seems to me that Gaia should be able to build such a transition just by knowing the from and to colors without involving the app...

> Why not make this a CSS thing?

Do we have examples of CSS properties for styling things outside of the DOM?  I can't think of any off the top of my head...

> In any case, if you do implement this, please add a "moz-" vendor prefix.

What would be the benefit of that?  I think if we determine that what we are aiming for here is the same as what Blink is looking to do we should try to use the same name.  And otherwise, adding a moz- prefix doesn't really make this any less proprietary.  I'm in general a bit sad on how much moz- prefixing we have been doing in Firefox OS... :(

Comment 21

[Kevin Grandon :kgrandon]

In gaia we currently want to control the opacity and color of the statusbar. Hope this doesn't throw a wrench into anyone's plans.

Comment 22

[Marcos Caceres [:marcosc]]

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #20)
> > Ok, I see. This still feels like a pretty poor fit tho. Pretty soon you will
> > want to be doing transitions, etc. and you will be needing a styling language.
> 
> You mean declaring a transition?  Do we want to do that?  It seems to me
> that Gaia should be able to build such a transition just by knowing the from
> and to colors without involving the app...

Oh, once non-Gaia developers find this stuff they will want control over it too.  

> > Why not make this a CSS thing?
> 
> Do we have examples of CSS properties for styling things outside of the DOM?
> I can't think of any off the top of my head...

Not exactly, but for example, scrollbars:
http://css-tricks.com/custom-scrollbars-in-webkit/

And we used to, it seems:
http://codemug.com/html/custom-scrollbars-using-css/

> > In any case, if you do implement this, please add a "moz-" vendor prefix.
> 
> What would be the benefit of that?  I think if we determine that what we are
> aiming for here is the same as what Blink is looking to do we should try to
> use the same name.  And otherwise, adding a moz- prefix doesn't really make
> this any less proprietary.

Unprefixed things are reserved for things that have undergone formal standardization (i.e., we have agreement amongst the web community in the form of a W3C spec OR it's in WHATWG HTML OR in the WHATWG Github with support from other browser vendors and the developer community). If we start breaking this rule (any more than we already do) it confuses developers and doesn't allow us to refine our ideas prior to standardization. 

If we want to make the Web the Google and Mozilla show, then that doesn't encourage Apple and Microsoft to play nice - and we all lose.  

>  I'm in general a bit sad on how much moz-
> prefixing we have been doing in Firefox OS... :(

If we don't want "moz-" and we want less proprietary stuff then we need to make more of an effort to standardize stuff. That means going through the appropriate channels (W3C or WHATWG).  

Apple and Microsoft have had the decency to respect the Web platform and clearly prefix their proprietary extensions for this as follows:

 * mapplication-navbutton-color,
 * apple-mobile-web-app-status-bar-style 

We should also be respectful to the Web platform and make sure that for things that are Firefox OS only we properly prefix stuff.

Comment 23

[Marcos Caceres [:marcosc]]

(In reply to Kevin Grandon :kgrandon from comment #21)
> In gaia we currently want to control the opacity and color of the statusbar.
> Hope this doesn't throw a wrench into anyone's plans.

You can do this by allowing CSS rgba() values, I guess:

```
<meta name="moz-header-color" value="rgba(200, 54, 54, 0.5)"> 
```

Comment 24

[Marcos Caceres [:marcosc]]

(In reply to Marcos Caceres [:marcosc] from comment #23)
> (In reply to Kevin Grandon :kgrandon from comment #21)
> > In gaia we currently want to control the opacity and color of the statusbar.
> > Hope this doesn't throw a wrench into anyone's plans.
> 
> You can do this by allowing CSS rgba() values, I guess:
> 
> ```
> <meta name="moz-header-color" value="rgba(200, 54, 54, 0.5)"> 
> ```

Just a question: if you change the background color and opacity, won't you also need to change the foreground color of the text?

Comment 25

[Dale Harvey (:daleharvey)]

Yup, we have code to detect colours and pick a contrasting colour

Comment 26

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Marcos Caceres [:marcosc] from comment #24)
> (In reply to Marcos Caceres [:marcosc] from comment #23)
> > (In reply to Kevin Grandon :kgrandon from comment #21)
> > > In gaia we currently want to control the opacity and color of the statusbar.
> > > Hope this doesn't throw a wrench into anyone's plans.
> > 
> > You can do this by allowing CSS rgba() values, I guess:
> > 
> > ```
> > <meta name="moz-header-color" value="rgba(200, 54, 54, 0.5)"> 
> > ```
> 
> Just a question: if you change the background color and opacity, won't you
> also need to change the foreground color of the text?

This is up to the UA to adjust the color. So the text color will be adjusted based on the background color, and the 'brand' color choosen by the web page to colorize the statusbar may also not be exactly what the page asked for (if the color is too bright for example).

Comment 27

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: brandcolor.patch

Same patch as before with a test. It uses the -moz prefix thing mostly because I don't want to block on this.

Comment 28

[(no longer active)]

Can we at least wait until next week to see what the Blink folks are up to?

Comment 29

[(no longer active)]

(In reply to Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) from comment #27)
> Created attachment 8443493 [details] [diff] [review]
> brandcolor.patch
> 
> Same patch as before with a test. It uses the -moz prefix thing mostly
> because I don't want to block on this.

Note that our API exposure guidelines ask us to not use vendor prefixes.  <https://wiki.mozilla.org/WebAPI/ExposureGuidelines>

Comment 30

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #28)
> Can we at least wait until next week to see what the Blink folks are up to?

Yep. Just posted the patch as it was lurking on my machine.

Comment 31

[Sam Foster [:sfoster] (he/him)]

This is under consideration again for 2.1. My take on the discussion so far is that the idea is both reasonable and possible but we need to hammer out the details wrt. standardization and also exactly what the end-result should be. Are we shooting for something like this: a meta tag in content causes some special system color value to be populated? E.g (all names placeholder and subject to bikeshedding)

// in content document
<meta id="appHeaderColor" name="moz-header-color" value="rgba(200, 54, 54, 0.5)">
// and to update in js: 
document.getElementById('appHeaderColor').setAttribute('value', 'rgba(200, 0, 54, 0.9)');

// which might get used in our system UI css like: 
.whatever { background-color: application-headerbar-color; }

Does that look right? What are the next steps to be able to get a commitment for using this feature in an upcoming release?

Comment 32

[Dale Harvey (:daleharvey)]

we would just do

mozbrowser.addEventListener('meta-change', function(e) { 
  if (e.name = 'moz-brand-color') { 
    statusbar.style.backgroundColor = e.content;
  }
});

something along those lines in the system app, no special css variable things, there will need to be additional processing for foreground text etc, working on the system app implementation would be useful, this part just needs coordinated with chrome to land as Ehsan said

Comment 33

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Dale Harvey (:daleharvey) from comment #32)
> we would just do
> 
> mozbrowser.addEventListener('meta-change', function(e) { 
>   if (e.name = 'moz-brand-color') { 
>     statusbar.style.backgroundColor = e.content;
>   }
> });
> 
> something along those lines in the system app, no special css variable
> things, there will need to be additional processing for foreground text etc,
> working on the system app implementation would be useful, this part just
> needs coordinated with chrome to land as Ehsan said

My first idea was also to change the statusbar color. Then I thought a bit more about it and I have a more invasive plan.

I would like to extend AppWindow height to always takes the full height of the device. And the appWindow will contains an element of the size of the statusbar.
Then this element will have the color defined by the app.

I would also like to explore if we can use -moz-element to render the content of the statusbar on top of it.

Basically that will offer us a more robust way of changing color than always altering the color of the statusbar (not efficient at app startup), while beeing compatible with edge gestures (the statusbar needs to move with the app window), and provide a cleaner transition when the app goes to background/foreground as the header will transition with it.

Comment 34

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Sam Foster [:sfoster] from comment #31)
> This is under consideration again for 2.1. My take on the discussion so far
> is that the idea is both reasonable and possible but we need to hammer out
> the details wrt. standardization and also exactly what the end-result should
> be. Are we shooting for something like this: a meta tag in content causes
> some special system color value to be populated? E.g (all names placeholder
> and subject to bikeshedding)
> 
> // in content document
> <meta id="appHeaderColor" name="moz-header-color" value="rgba(200, 54, 54,
> 0.5)">
> // and to update in js: 
> document.getElementById('appHeaderColor').setAttribute('value', 'rgba(200,
> 0, 54, 0.9)');
> 
> // which might get used in our system UI css like: 
> .whatever { background-color: application-headerbar-color; }
> 
> Does that look right? What are the next steps to be able to get a commitment
> for using this feature in an upcoming release?

The way it work is basically that a <meta> tag in content will fire an event on the <iframe mozbrowser> that contains this particular content.

Then the system app could apply any logic to any UI needed. I think the chrome idea behing brand-color is that it may also apply to other elements than the statusbar (still unclear as there is no doc).

So on our case for example I can imagine us rendering a window.alert / <select> with the background gradient of the color specified by the app. This way those dialogs will keep the system UX, while looking more integrated into the app itself.

Comment 35

[Marcos Caceres [:marcosc]]

So the Google guys have created a spec and added "brand-color" to the HTML meta names registry:

http://wiki.whatwg.org/wiki/MetaExtensions

Spec:
https://docs.google.com/a/chromium.org/document/d/1OipHnEozoncRZpVqSr-Reawp5O0eLWk_ySg5J6T150s

If we choose to follow their lead (and use "brand-color"), then we can drop the vendor prefixing.

Comment 36

[Marcos Caceres [:marcosc]]

Put Google's spec up on the GitHub. Now includes processing model. Being discussed at the WHATWG ATM:

https://github.com/whatwg/meta-brand-color

If anything significant changes, will report back.

Comment 37

[Marcos Caceres [:marcosc]]

(In reply to Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) from comment #33)
> (In reply to Dale Harvey (:daleharvey) from comment #32)
> > we would just do
> > 
> > mozbrowser.addEventListener('meta-change', function(e) { 
> >   if (e.name = 'moz-brand-color') { 
> >     statusbar.style.backgroundColor = e.content;
> >   }
> > });
> > 
> > something along those lines in the system app, no special css variable
> > things, there will need to be additional processing for foreground text etc,
> > working on the system app implementation would be useful, this part just
> > needs coordinated with chrome to land as Ehsan said
> 
> My first idea was also to change the statusbar color. Then I thought a bit
> more about it and I have a more invasive plan.
> 
> I would like to extend AppWindow height to always takes the full height of
> the device. And the appWindow will contains an element of the size of the
> statusbar.
> Then this element will have the color defined by the app.
> 
> I would also like to explore if we can use -moz-element to render the
> content of the statusbar on top of it.
> 
> Basically that will offer us a more robust way of changing color than always
> altering the color of the statusbar (not efficient at app startup), while
> beeing compatible with edge gestures (the statusbar needs to move with the
> app window), and provide a cleaner transition when the app goes to
> background/foreground as the header will transition with it.

Would having this also in the manifest help with app start-up? At least you would have it as you are creating the containing window (and it could serve as the default as the user navigates around). The meta tag could then override the default as needed... when the meta element is removed or in error, the default from the manifest could be used.

Comment 38

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Marcos Caceres [:marcosc] from comment #37)
> (In reply to Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails,
> needinfo? please) from comment #33)
> > (In reply to Dale Harvey (:daleharvey) from comment #32)
> > > we would just do
> > > 
> > > mozbrowser.addEventListener('meta-change', function(e) { 
> > >   if (e.name = 'moz-brand-color') { 
> > >     statusbar.style.backgroundColor = e.content;
> > >   }
> > > });
> > > 
> > > something along those lines in the system app, no special css variable
> > > things, there will need to be additional processing for foreground text etc,
> > > working on the system app implementation would be useful, this part just
> > > needs coordinated with chrome to land as Ehsan said
> > 
> > My first idea was also to change the statusbar color. Then I thought a bit
> > more about it and I have a more invasive plan.
> > 
> > I would like to extend AppWindow height to always takes the full height of
> > the device. And the appWindow will contains an element of the size of the
> > statusbar.
> > Then this element will have the color defined by the app.
> > 
> > I would also like to explore if we can use -moz-element to render the
> > content of the statusbar on top of it.
> > 
> > Basically that will offer us a more robust way of changing color than always
> > altering the color of the statusbar (not efficient at app startup), while
> > beeing compatible with edge gestures (the statusbar needs to move with the
> > app window), and provide a cleaner transition when the app goes to
> > background/foreground as the header will transition with it.
> 
> Would having this also in the manifest help with app start-up? At least you
> would have it as you are creating the containing window (and it could serve
> as the default as the user navigates around). The meta tag could then
> override the default as needed... when the meta element is removed or in
> error, the default from the manifest could be used.

I would like to say yes, but the email app for example makes it tricky as the header color depends on the page used for startup. And this one varies in this case if you are already logged in or not :/

Comment 39

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: brandcolor.patch

Fabrice,

this is a simple brand-color support. I will have a followup to do to listen for DOMMetaRemoved (which we completely ignore for now) and the processing model will be done on the system app side (see bug 1033364).

Comment 40

[Marcos Caceres [:marcosc]]

(In reply to Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) from comment #38)
> I would like to say yes, but the email app for example makes it tricky as
> the header color depends on the page used for startup. And this one varies
> in this case if you are already logged in or not :/

This is really helpful feedback. Thanks!

Comment 41

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 8450273 [details] [diff] [review]
brandcolor.patch

Oups. Forgot to ask the review.

Comment 42

[[:fabrice] Fabrice Desré]

Comment on attachment 8450273 [details] [diff] [review]
brandcolor.patch

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

::: dom/browser-element/mochitest/browserElement_Metachange.js
@@ +141,4 @@
>        SimpleTest.finish();
>      } else {
>        ok(false, 'Too many metachange events.');
>      }

that would be nice to add a test to change the value of the existing meta since this is how we plan to use it in gaia apps.

Comment 43

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: dommetachanged.patch

Not sure who is a good reviewer for this part of the code. So I asked bz, feel free to redirect.

Comment 44

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: brandcolor.patch

Fabrice, the changes are a bit more intrusive with DOMMetaChanged, so it sounds like you will a bit more things to review than just a new test :)

Also, I'm unsure about what needs to happen for application-name on the change of the meta, or its removal, so I just kept the previous behavior for now and did something only on a DOMMetaAdded event.

Would be nice to have something a bit more consistent between application-name and brand-color though.

Comment 45

[[:fabrice] Fabrice Desré]

Comment on attachment 8451366 [details] [diff] [review]
brandcolor.patch

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

::: dom/browser-element/BrowserElementChildPreload.js
@@ +552,3 @@
>  
> +  _applicationNameChangedHandler: function(eventType, target) {
> +    if (eventType !== 'DOMMetaAdded') {

file a follow-up for the other cases and put the bug number here.

Comment 46

[Marcos Caceres [:marcosc]]

Agreed with Google that we would call this "theme-color". Hopefully the bikeshedding is now done.

Comment 47

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8451365 [details] [diff] [review]
dommetachanged.patch

Please just add an AfterSetAttr override instead of doing the mutation observer thing.

r=me with that done.

Comment 48

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Sent on try with AfterSetAttr and s/brand-color/theme-color: https://tbpl.mozilla.org/?tree=Try&rev=8c87c1288191

Comment 49

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/bb1df1018a62
https://hg.mozilla.org/integration/mozilla-inbound/rev/bb1df1018a62

Comment 50

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Where's the intent to implement for that event?

Comment 51

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to :Ms2ger from comment #50)
> Where's the intent to implement for that event?

AFAICT DOMMetaAdded, DOMMetaRemoved and DOMMetaChanged are not intended to be consumed by content, but only by extensions and internal chrome code.

Or did I misunderstood the question ?

Comment 52

[Boris Zbarsky [:bzbarsky]]

Vivien is correct: if you look at the code, the event is fired chromeonly.  So there is no need for an intent to anything; this is not web-exposed.

Comment 53

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Got it; CreateAndDispatchEvent doesn't sound like it'd be chrome-only. Sorry for the disruption.

Comment 54

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/bb1df1018a62
https://hg.mozilla.org/mozilla-central/rev/ce024ab45117

Comment 55

[Etienne Segonzac (:etienne)]

I think the brandcolor.patch didn't land, we're still watching "theme-color" on the gecko side...
http://dxr.mozilla.org/mozilla-central/source/dom/browser-element/BrowserElementChildPreload.js#543

Comment 56

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Etienne Segonzac (:etienne) from comment #55)
> I think the brandcolor.patch didn't land, we're still watching "theme-color"
> on the gecko side...
> http://dxr.mozilla.org/mozilla-central/source/dom/browser-element/
> BrowserElementChildPreload.js#543

As discussed on IRC, the new name is theme-color :)

Comment 57

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'll defer to Marcos here.

Comment 58

[Eric Chang [:ericcc] [:echang]]

https://moztrap.mozilla.org/manage/cases/?filter-id=14405

Comment 59

[Eric Chang [:ericcc] [:echang]]

Verified User story is fixed.  status bar changed color according to apps.

Gaia      2be78d83a760fa3b9638fe51c266b442d14597f1
Gecko     https://hg.mozilla.org/mozilla-central/rev/1db35d2c9a2f
BuildID   20140831160203
Version   34.0a1
ro.build.version.incremental=110
ro.build.date=Fri Jun 27 15:57:58 CST 2014
B1TC00011230

Comment 60

[Michael]

This doesn't seem to work on Firefox for Android?

Comment 61

[ChristianOliff]

As Michael stated above a year ago, this doesn't seem to work on Firefox 55 for Android 6 (Marshmallow). Should this Bug be re-opened?

Comment 62

[Jan Henning [:JanH]]

As far as I can tell, this bug was only for Firefox OS. See bug 1098544 and bug 1119628 for Fennec.