Photon landing strategy

Mike Conley mconley at
Thu Mar 30 13:33:07 UTC 2017

Maybe I'm missing something, but I see the following advantages of this
approach over using a project branch:

1) Easy one: we don't have to maintain a project branch! No periodic
merging. Presumably less probability of having to deal with merge
conflicts due to changes in mozilla-central. No having to watch multiple

jaws and I maintained the Holly backout branch during the development of
the Australis theme, and I remember that being a bit of a pain.

2) Easy to manually turn on and off. Among other things, it will be
easier for volunteer contributors to participate and try the new theme
while it's being built, spot problems and file bugs against it (since
they won't have to run a separate executable that updates on a different

3) Probably easy to programmatically turn on and off. I know that UR and
UX is interested in doing experiments and science with the changes that
we're making to ensure that we're actually making the browser experience
better. Shipping it as a separate theme gives us the potential of
turning it on temporarily for some subset of our user population to do
A/B testing.

I'm not wholly against a project branch, but I think there are some nice
advantages of writing it as a separate built-in theme that we should
consider as well.

But I'm also pretty easy going. Do what works. :)


On 2017-03-30 4:42 AM, Dão Gottwald wrote:
> It's quite possible. Could just be a different theme folder with a
> build-time switch. However, I don't see how that's better than a project
> branch. It seems like a different way to fork stuff with roughly the
> same overhead due to having to synchronize it.
> 2017-03-30 0:04 GMT+02:00 Mike Conley <mconley at
> <mailto:mconley at>>:
>     Hey folks,
>     Not sure if my suggestion got lost in the shuffle, or if it's
>     malodourous / obvious enough that it didn't prompt reply, but would
>     landing the appearance changes as a new complete theme be out of the
>     question? I know we're tearing out the support for that stuff, at
>     least for third-party extensions, but for this kind of theme
>     development, it seems quite well suited.
>     Or am I wrong?
>     -Mike
>     On 29 March 2017 at 08:37, Dão Gottwald <dgottwald at
>     <mailto:dgottwald at>> wrote:
>         2017-03-29 14:18 GMT+02:00 Gijs Kruitbosch
>         <gkruitbosch at <mailto:gkruitbosch at>>:
>             On 29/03/2017 11:42, Dão Gottwald wrote:
>>             2017-03-28 14:22 GMT+02:00 Gijs Kruitbosch
>>             <gkruitbosch at <mailto:gkruitbosch at>>:
>>                 On 28/03/2017 08:06, Chris Peterson wrote:
>>                     It seems like some of the smaller visible UI
>>                     changes could probably ship in 55/56 without
>>                     needing a pref. Users probably won't notice some
>>                     of the UI polish features until everything is into
>>                     place in 57. Shipping these smaller bits in 55/56
>>                     would give us more testing.
>>                 Can you elaborate on this? What are "small visible UI
>>                 changes" that users "won't notice"? I'm skeptical
>>                 these even exists, looking at (for instance) things
>>                 like
>>                 <>
>>                 . comes to mind... And yes, of
>>                 course these are extreme examples, but I'm also
>>                 looking at the mockups I've seen and thinking I don't
>>                 see anything that falls in the "small polish" category
>>                 in our main theming & structural changes.
>>             You're reading Chris too literally.
>             I fail to understand what is "literal" about my reading and
>             how yours is less so, and I'm disappointed that you're
>             turning an honest question into "you're (reading it) wrong".
>         No need to take it personally, I was just trying to answer your
>         question. Clearly, there is no UI change that is guaranteed to
>         go unnoticed with every single user. Reworded as "most users
>         won't notice", are you still skeptical that such changes exist?
>>             We're not trying to make it look like there were no
>>             changes at all between 54, 55 and 56, but the changes
>>             shouldn't particularly stand out and take away from Photon.
>>             <snip>
>>             For the visual refresh, I'm trying to be smart and divide
>>             the work into parts that can be tackled early and parts
>>             that should wait. Nihanth is going to start with
>>             integrating our new SVG toolbar button icons in bug
>>             1347543 -- this should land when it's ready (I've checked
>>             with shorlander, he's fine with this)
>             I wouldn't have thought that changing the icons over to the
>             Photon icon set would be something we'd do before 57, as
>             that's pretty noticeable.
>             (To be clear, I'm not arguing that we shouldn't do this
>             stuff prior to 57 if people are on board with it, but to me
>             this is a surprising example of "small changes".)
>         From what I've seen the icons are a bit sharper and thinner, but
>         in the grand scheme of things it's a rather subtle and
>         incremental change.
>         dao
>         _______________________________________________
>         Photon-dev mailing list
>         Photon-dev at <mailto:Photon-dev at>
>         <>
> _______________________________________________
> Photon-dev mailing list
> Photon-dev at

More information about the Photon-dev mailing list