Closed Bug 1013913 Opened 6 years ago Closed 5 years ago

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

Categories

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

x86
macOS
defect
Not set

Tracking

()

VERIFIED FIXED
2.1 S3 (29aug)
feature-b2g 2.1

People

(Reporter: daleharvey, Assigned: vingtetun)

References

()

Details

(Keywords: dev-doc-needed, Whiteboard: [2.1-feature-qa+][systemsfe])

Attachments

(2 files, 5 obsolete files)

No description provided.
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
Attached patch meta.mozstatusbar.patch (obsolete) — Splinter Review
Completely untested patch.
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.
Flags: needinfo?(dale)
Flags: needinfo?(21)
I am not gonna be able to get this landable today, happy to implement and hope it makes an uplift
Flags: needinfo?(dale)
Needinfo'ing Ehsan and Jonas, just to make sure that it is actually something we want to do.
Flags: needinfo?(jonas)
Flags: needinfo?(ehsan)
Flags: needinfo?(21)
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...
Flags: needinfo?(ehsan)
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
(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.
(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.
Attached patch brandcolor.patch (obsolete) — Splinter Review
Here is a patch that use brand-color. Still need to add tests.
Attachment #8435926 - Attachment is obsolete: true
Attached patch system.app.changes.patch (obsolete) — Splinter Review
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.
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 :)
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.
(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.
(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.
(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.
(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
(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...
(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.
(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... :(
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.
(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.
(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)"> 
```
(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?
Yup, we have code to detect colours and pick a contrasting colour
(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).
Attached patch brandcolor.patch (obsolete) — Splinter Review
Same patch as before with a test. It uses the -moz prefix thing mostly because I don't want to block on this.
Can we at least wait until next week to see what the Blink folks are up to?
Keywords: dev-doc-needed
(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>
(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.
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?
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
(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.
(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.
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.
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.
(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.
(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 :/
Summary: Add meta name="header-color" to have configurable status bar colour on fxos → Add meta name="brand-color" to have configurable status bar color
Attached patch brandcolor.patch (obsolete) — Splinter Review
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).
Attachment #8442123 - Attachment is obsolete: true
Attachment #8442125 - Attachment is obsolete: true
Attachment #8443493 - Attachment is obsolete: true
(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 on attachment 8450273 [details] [diff] [review]
brandcolor.patch

Oups. Forgot to ask the review.
Attachment #8450273 - Flags: review?(fabrice)
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.
Attachment #8450273 - Flags: review?(fabrice) → feedback+
Not sure who is a good reviewer for this part of the code. So I asked bz, feel free to redirect.
Attachment #8451365 - Flags: review?(bzbarsky)
Attached patch brandcolor.patchSplinter Review
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.
Attachment #8450273 - Attachment is obsolete: true
Attachment #8451366 - Flags: review?(fabrice)
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.
Attachment #8451366 - Flags: review?(fabrice) → review+
Summary: Add meta name="brand-color" to have configurable status bar color → Add meta name="theme-color" to have configurable status bar color
Agreed with Google that we would call this "theme-color". Hopefully the bikeshedding is now done.
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.
Attachment #8451365 - Flags: review?(bzbarsky) → review+
Where's the intent to implement for that event?
Flags: needinfo?(21)
(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 ?
Flags: needinfo?(21) → needinfo?(Ms2ger)
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.
Got it; CreateAndDispatchEvent doesn't sound like it'd be chrome-only. Sorry for the disruption.
Flags: needinfo?(Ms2ger)
https://hg.mozilla.org/mozilla-central/rev/bb1df1018a62
https://hg.mozilla.org/mozilla-central/rev/ce024ab45117
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
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
Flags: needinfo?(21)
(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 :)
Flags: needinfo?(21)
QA Whiteboard: [2.1-feature-qa+]
QA Contact: jsmith
QA Whiteboard: [2.1-feature-qa+]
Whiteboard: [2.1-feature-qa+]
Flags: in-moztrap?(jsmith)
Flags: in-moztrap?(jsmith) → in-moztrap?(mozbugs.retornam)
QA Contact: jsmith → mozbugs.retornam
Flags: in-moztrap?(mozbugs.retornam) → in-moztrap?(echang)
QA Contact: mozbugs.retornam → echang
Flags: in-moztrap?(echang) → in-moztrap-
QA Whiteboard: [COM=DOM]
I'll defer to Marcos here.
Flags: needinfo?(jonas)
feature-b2g: --- → 2.1
Whiteboard: [2.1-feature-qa+] → [2.1-feature-qa+][systemsfe]
Target Milestone: mozilla33 → 2.1 S3 (29aug)
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
Status: RESOLVED → VERIFIED
QA Whiteboard: [COM=DOM]
This doesn't seem to work on Firefox for Android?
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?
As far as I can tell, this bug was only for Firefox OS. See bug 1098544 and bug 1119628 for Fennec.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.