The dynamic theme proposal is too broad for a v1

[msujaws]

The proposal for dynamic themes is very broad for a version 1.

The proposal in https://github.com/nt1m/WebExtensions-Theming-API/commit/901b783174f1ae545788095068df1bbeb4f3056e shows some JavaScript that sets details of the theme based on some custom JavaScript switch.

We should take a more guarded approach for this first go at the API, providing possible "events" to theme devs which can be added to by Firefox devs in the future.

For example:

{
  "version": "2.6",
  "name": "camo theme",
  "theme": {
    "images" : {
      "theme_frame" : "images/theme_frame_camo.png",
      "theme_frame_overlay" : "images/theme_frame_stripe.png",
      "theme_toolbar" : "images/theme_toolbar_camo.png",
      "theme_ntp_background" : "images/theme_ntp_background_norepeat.png",
      "theme_ntp_attribution" : "images/attribution.png"
    },
    "colors" : {
      "frame" : [71, 105, 91],
      "toolbar" : [207, 221, 192],
      "ntp_text" : [20, 40, 0],
      "ntp_link" : [36, 70, 0],
      "ntp_section" : [207, 221, 192],
      "button_background" : [255, 255, 255]
    },
    "tints" : {
      "buttons" : [0.33, 0.5, 0.47]
    },
    "properties" : {
      "ntp_background_alignment" : "bottom"
    },
    "onMorning": {
      "images": {
        "theme_frame" : "images/theme_frame_morning.png",
      },
    }, 
    "onAfternoon": {
      "images": {
        "theme_frame" : "images/theme_frame_afternoon.png",
      },
    }, 
    "onEvening": {
      "images": {
        "theme_frame" : "images/theme_frame_evening.png",
      },
    }, 
    "onNight": {
      "images": {
        "theme_frame" : "images/theme_frame_night.png",
      },
    }, 
    "onNight": {
      "images": {
        "theme_frame" : "images/theme_frame_night.png",
      },
    }, 
  }
}

where we could define morning as 0600-1200, afternoon as 1200-1700, evening as 1700-2000, and night as 2000-0600. Alternatively this could use a sunrise/sunset algorithm based on the system's timezone.

Other events could be added such as "onTabOverflow", "onTabUnderflow", etc.

The point of reducing the scope and breadth of the API is to both make it simpler for theme devs (not requiring knowledge of JS), and also to limit potential attack surface and abilities for theme devs to unknowingly (or knowingly) slow down Firefox with expensive JS functions.

[msujaws]

If we must allow for custom JS, we could keep it in the JSON like so:

 ... snippet ...
"onEvent": [{
  "callback": "function() { ... }",
  "images": {
    "theme_frame" : "images/theme_frame_callback1.png"
  }
},{
  "callback": "function() { ... }",
  "images": {
    "theme_frame" : "images/theme_frame_callback2.png"
  }
}]
... snippet ...

The callback function would run in a separate thread and wouldn't have access to any UI elements or details about the browser. If the callback function returned true then the theme override would be applied, false and no theme override applied. In collisions we could either just choose the last item in the array to get applied, though that may not be obvious to theme devs.

[nt1m]

Thanks for taking your time to write this proposal!

I like the fact that this approach is safe, and can be reached by a bigger developer audience. About the custom JS part, it seems unusal for Chrome APIs to include JS into a manifest, but I do like the fact that it runs in a separate thread for safety. I'm thinking the approach wouldn't be enough for add-ons like Personas rotator or VivaldiFox. I guess some kind of messaging system from the background page could work with the callback?

I also wonder if we can tight up this proposal and the 3rd one to be closer.