Closed Bug 1057346 Opened 10 years ago Closed 9 years ago

Devtools styling API

Categories

(Add-on SDK Graveyard :: General, defect, P1)

Product:
Add-on SDK Graveyard
Component:
General
Platform:
x86_64
Windows 7
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla37

People

(Reporter: Honza, Assigned: Honza)

References

Details

Attachments

(2 files)

Patch (pull on github.com/mozilla/addon-sdk)
48 bytes, text/x-github-pull-request
zer0
: review+
Details | Review
failures.txt
16.45 KB, text/plain
Details 
Platform (DevTools) API for theme (un)registration landed this week and we should make sure these are also exposed through the Add-on SDK.

Original bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1038562

Here is an example-extension that shows how to use the platform API
https://github.com/firebug/extension-examples/tree/master/CustomTheme

---

A proposal how the Add-on SDK API could look like:

// Definition of a panel
const MyPanel = Class({
  extends: Panel,
  // ...
});

// Definition of a theme
const MyTheme = Class({
  extends: Theme,

  id: "myTheme",
  label: "Custom Theme",
  stylesheets: ["./theme-styles.css"],
  classList: ["custom-theme"],

  // Optional hooks
  onApply: function(win, oldTheme) {},
  onUnapply: function(win, newTheme) {},
});

const myTool = new Tool({
  name: "My Tool",
  panels: {
    myPanel: MyPanel
  },
  themes: {
    myTheme: MyTheme
  }
});

The 'Theme' object is also disposable, so the unregistration happens automatically.

Not sure about the 'Tool' name, it could be a bit higher abstract name, but it's already there and not sure how we would feel about changing it.

Thoughts?

Honza
Flags: needinfo?(rFobic)
Could you please point out what the `win` and `theme` arguments are in the hooks ? I think in this case we would want to expose those hooks same as I proposed in case of `toolbar/panel`:

```js
var { onEnable, onDisable } = require("dev/theme/hooks")
onEnable.define(MyTheme, (window, oldTheme) => {
})
onDisable.define(MyTheme, (window, newTheme) => {
})
```

Other than that I think all looks good to me.

As of `Tool` name I agree better naming would have being great, do you have any suggestions ? We won't get rid of `Tool` at this point, but we could expose the same API with a different name and deprecate old name over time.


```
Flags: needinfo?(rFobic)
(In reply to Irakli Gozalishvili [:irakli] [:gozala] [@gozala] from comment #1)
> Could you please point out what the `win` and `theme` arguments are in the
> hooks ?
`win`: the window where the theme is being applied. Note that
the Toolbox UI is composed from many iframes and theme must be applied
to every window/iframe.

`oldTheme`: ID of the previous theme (might be undefined)
`newTheme`: ID of the new theme (being applied)


> I think in this case we would want to expose those hooks same as I
> proposed in case of `toolbar/panel`:
> 
> ```js
> var { onEnable, onDisable } = require("dev/theme/hooks")
> onEnable.define(MyTheme, (window, oldTheme) => {
> })
> onDisable.define(MyTheme, (window, newTheme) => {
> })
> ```
Ok, make sense to me!


> Other than that I think all looks good to me.
> 
> As of `Tool` name I agree better naming would have being great, do you have
> any suggestions ?
Nope. Let's see how the name fits as we more forward with the other DevTools API.

Honza
Summary: Theme API → Devtools styling API
(In reply to Jan Honza Odvarko [:Honza] from comment #2)
> (In reply to Irakli Gozalishvili [:irakli] [:gozala] [@gozala] from comment
> #1)
> > Could you please point out what the `win` and `theme` arguments are in the
> > hooks ?
> `win`: the window where the theme is being applied. Note that
> the Toolbox UI is composed from many iframes and theme must be applied
> to every window/iframe.
> 

Hmmm. I was under impression that we used seamless iframes (see https://developer.mozilla.org/en/docs/Web/HTML/Element/iframe#attr-seamless) so that outer styles would automatically apply to each panel iframe. If that's not a case maybe we should consider switching devtools to seamless iframes ?
> so that outer styles would automatically apply to each panel iframe.
I am not sure whether we actually want this.

> If that's not a case maybe we should consider switching devtools
> to seamless iframes ?
Question for Brian...

Honza
(In reply to Jan Honza Odvarko [:Honza] from comment #0)
> const MyTheme = Class({
>   extends: Theme,
> 
>   id: "myTheme",
>   label: "Custom Theme",
>   stylesheets: ["./theme-styles.css"],
>   classList: ["custom-theme"],
> 
>   // Optional hooks
>   onApply: function(win, oldTheme) {},
>   onUnapply: function(win, newTheme) {},
> });

(In reply to Irakli Gozalishvili [:irakli] [:gozala] [@gozala] from comment #1)
> Could you please point out what the `win` and `theme` arguments are in the
> hooks ? I think in this case we would want to expose those hooks same as I
> proposed in case of `toolbar/panel`:
> 
> ```js
> var { onEnable, onDisable } = require("dev/theme/hooks")
> onEnable.define(MyTheme, (window, oldTheme) => {
> })
> onDisable.define(MyTheme, (window, newTheme) => {
> })
> ```

This brings up a point that onApply is mostly interesting only in the context of doing extra stuff within a window (like maybe adding a new element inside the window when a theme is applied and removing it when it is unapplied).  *Not* for catching the time when a user has selected the new theme from the options menu.

I think there is usefulness in an onEnable / onDisable functionality that fires once when the pref changed (like if the theme is clicked on in the options panel).  It seems like an extension that includes a theme along with other features may want to be a friendly neighbor and not add the new features unless if the theme was enabled.
(In reply to Irakli Gozalishvili [:irakli] [:gozala] [@gozala] from comment #4)
> (In reply to Jan Honza Odvarko [:Honza] from comment #2)
> > (In reply to Irakli Gozalishvili [:irakli] [:gozala] [@gozala] from comment
> > #1)
> > > Could you please point out what the `win` and `theme` arguments are in the
> > > hooks ?
> > `win`: the window where the theme is being applied. Note that
> > the Toolbox UI is composed from many iframes and theme must be applied
> > to every window/iframe.
> > 
> 
> Hmmm. I was under impression that we used seamless iframes (see
> https://developer.mozilla.org/en/docs/Web/HTML/Element/iframe#attr-seamless)
> so that outer styles would automatically apply to each panel iframe. If
> that's not a case maybe we should consider switching devtools to seamless
> iframes ?

It doesn't do this right now.  After a quick check, it doesn't seem that parent styles are being applied after adding the seamless attribute to the tool iframes and removing theme-switching.js from debugger.xul (maybe has to do with the fact that the styles are loaded in the parent frame as author styles with StylesheetUtils?).  

Assuming that I'm just missing something there, the two issues I can think of off the top of my head with doing this would be:

1) This may be undesirable for an extension like Ember Inspector that brings along its own UI.
2) We send out the onApply / onUnapply messages to each individual window by listening to the theme pref changing in theme-switching.js (which is loaded in each frame).  This guarantees that we call these events at exactly the right time once the stylesheet is added or removed.

As for (1), we could allow a tool to opt-out of this.  Right now the theme switching is opt-in by including theme-switching.js in your document.
As for (2), there is probably a different way to deal with this to the same effect - have a single listener then traverse all "seamless" windows recursively and fire off the onApply/onUnapply events on each one.
(In reply to Brian Grinstead [:bgrins] from comment #6)
> It seems like an extension that includes a theme along with
> other features may want to be a friendly neighbor and not add the new
> features unless if the theme was enabled.
We were discussing this yesterday at Firebug weekly meeting and we also agreed
that this is the right way to go.

Honza
Here is an update for Theme API suggestion.

A support for theme inheritance we discussed with Matteo
last week is included.

const { Theme, LightTheme }  = require("dev/theme/core")

// Definition of a custom theme. The label 'My Theme' is used
// for a new theme option available in the Options panel
// (next to the default Light and Dark themes)
// The new theme is derived from Light theme, changing just
// some aspects of it (e.g. a color of a few JS keywords in
// the debugger panel within CodeMiror editor).
// The styles.css file defines custom CSS rules
let MyTheme = Class({
  extends: LightTheme,
  label: "My Theme",
  styles: Style({
    uri: data.self.uri("./styles.css")
  },
});

// Definition of a new theme. This theme doesn't use any
// CSS from the default themes.
// This example also show that it's possible to provide new
// CSS defined in a file or inline (see the 'source' prop).
let MyTheme = Theme({
  label: "My Theme",
  styles: Style({
    uri: data.self.uri("./styles.css"),
    source: "<inline styles>"
  },
});

// Theme hooks can be provided using 'define' method.
var { onEnable, onDisable } = require("dev/theme/hooks")
onEnable.define(MyTheme, (window, oldTheme) => {});
onDisable.define(MyTheme, (window, newTheme) => {});

// ... or by classical OOP method override.
let MyTheme = Theme({
  label: "My Theme",
  styles: Style({
    uri: data.self.uri("./styles.css")
  },
  onEnable: function(window, oldTheme) {}
  onDisable: function(window, newTheme) {}
});

// Registration of a custom theme is done through
// the existing 'Tool' object. Theme instances
// are disposable, so it's unregistered automatically
// by the framework.
const myTool = new Tool({
  name: "My Tool",
  themes: {
    myTheme: MyTheme
  }
});

Thoughts?

If this sounds good I can continue with new JEP for this
and start implementation.

Honza
(In reply to Jan Honza Odvarko [:Honza] from comment #9)
> Here is an update for Theme API suggestion.
> 
> A support for theme inheritance we discussed with Matteo
> last week is included.
> 
> const { Theme, LightTheme }  = require("dev/theme/core")
> 
> // Definition of a custom theme. The label 'My Theme' is used
> // for a new theme option available in the Options panel
> // (next to the default Light and Dark themes)
> // The new theme is derived from Light theme, changing just
> // some aspects of it (e.g. a color of a few JS keywords in
> // the debugger panel within CodeMiror editor).
> // The styles.css file defines custom CSS rules
> let MyTheme = Class({
>   extends: LightTheme,
>   label: "My Theme",
>   styles: Style({
>     uri: data.self.uri("./styles.css")
>   },
> });
> 
> // Definition of a new theme. This theme doesn't use any
> // CSS from the default themes.
> // This example also show that it's possible to provide new
> // CSS defined in a file or inline (see the 'source' prop).
> let MyTheme = Theme({
>   label: "My Theme",
>   styles: Style({
>     uri: data.self.uri("./styles.css"),
>     source: "<inline styles>"
>   },
> });
> 

Will this be replacing gDevTools.registerTheme, or is it just a more stable wrapper of it?

> // Theme hooks can be provided using 'define' method.
> var { onEnable, onDisable } = require("dev/theme/hooks")
> onEnable.define(MyTheme, (window, oldTheme) => {});
> onDisable.define(MyTheme, (window, newTheme) => {});
> 
> // ... or by classical OOP method override.
> let MyTheme = Theme({
>   label: "My Theme",
>   styles: Style({
>     uri: data.self.uri("./styles.css")
>   },
>   onEnable: function(window, oldTheme) {}
>   onDisable: function(window, newTheme) {}
> });

The second option here is more clear and obvious to me.  IMO we should only provide one way to do things to simplify usage and documentation unless if there is a strong reason to have two.
 
> // Registration of a custom theme is done through
> // the existing 'Tool' object. Theme instances
> // are disposable, so it's unregistered automatically
> // by the framework.
> const myTool = new Tool({
>   name: "My Tool",
>   themes: {
>     myTheme: MyTheme
>   }
> });

So when you say registration is done on a Tool, are you going to have to register for each tool individually?  The current registration happens at the toolbox level, once registering it is automatically loaded inside every tool immediately.
(In reply to Brian Grinstead [:bgrins] from comment #10)
> (In reply to Jan Honza Odvarko [:Honza] from comment #9)
> Will this be replacing gDevTools.registerTheme, or is it just a more stable
> wrapper of it?
It's just a more stable wrapper, the logic underneath stays
exactly the same. Also note that the other goal here is to make things
a bit simpler by automating the 'classList' usage
(e.g. super theme class name is included automatically in the list)

> The second option here is more clear and obvious to me. 
Agree, I'd also prefer it.

> So when you say registration is done on a Tool, are you going to have to
> register for each tool individually?
No, it should be done just once.

Honza
(In reply to Jan Honza Odvarko [:Honza] from comment #11)
> (In reply to Brian Grinstead [:bgrins] from comment #10)
> > (In reply to Jan Honza Odvarko [:Honza] from comment #9)
> > So when you say registration is done on a Tool, are you going to have to
> > register for each tool individually?
> No, it should be done just once.

If the Tool object is mapping to a single panel I don't see why the registration would happen at this level.  Really, theme registration is even bigger than a single Toolbox as a change will affect all opened toolboxes.  Is there a more global object available where the registration could occur?
(In reply to Brian Grinstead [:bgrins] from comment #12)
> If the Tool object is mapping to a single panel I don't see why the
> registration would happen at this level.  Really, theme registration is even
> bigger than a single Toolbox as a change will affect all opened toolboxes. 
> Is there a more global object available where the registration could occur?
Yeah, I understand the point (I was thinking about the same when asking for
more abstract name in comment #0).

In any case, does anyone have an answer to that? Irakli?

Honza
I need some feedback, please see comment #9

Thanks
Honza
Flags: needinfo?(zer0)
Flags: needinfo?(rFobic)
(In reply to Jan Honza Odvarko [:Honza] from comment #9)
> Here is an update for Theme API suggestion.
> 
> A support for theme inheritance we discussed with Matteo
> last week is included.
> 
> const { Theme, LightTheme }  = require("dev/theme/core")
> 
> // Definition of a custom theme. The label 'My Theme' is used
> // for a new theme option available in the Options panel
> // (next to the default Light and Dark themes)
> // The new theme is derived from Light theme, changing just
> // some aspects of it (e.g. a color of a few JS keywords in
> // the debugger panel within CodeMiror editor).
> // The styles.css file defines custom CSS rules
> let MyTheme = Class({
>   extends: LightTheme,
>   label: "My Theme",
>   styles: Style({
>     uri: data.self.uri("./styles.css")
>   },
> });

I think that either you use `Theme` all the time, or `Class` – in case of `Theme`, you will have an `extends` property too:

  let MyLightTheme = Theme({
    extends: LightTheme, // it's another `Theme` object
    label: "My Light Theme",
    styles: Style({
      uri: "./styles.css" // you don't need `data.url` anymore
    })
  });

The point is: someone has to do some "magic" behind the scene, because if you just inherit a class, you override the property of that class: if you create an instance of `MyLightTheme`, you'll only have the style defined there. So, either you use `Class` all the time, and in `Tool` API you crawl the prototype's chain, to collect all the "styles"; or you have a `Theme` class that returns a `Theme` object, that at the time of initialization inherits the styles of the theme set in the `extends`, or just keep a `extends` reference and have a method / getter to do so.

In my personal opinion, I think it's better use `Theme`.

> > The second option here is more clear and obvious to me. 
> Agree, I'd also prefer it.

Usually in SDK we have both. The low level API are the "functional" ones, and then in High Level API, we exposed them via methods, using the low level ones. An example could be the `show` method in sidebar. However, I don't think it's a blocker.

> 
> > So when you say registration is done on a Tool, are you going to have to
> > register for each tool individually?
> No, it should be done just once.
> 
> Honza
Flags: needinfo?(zer0)
Target Milestone: --- → mozilla37
Pull request
https://github.com/mozilla/addon-sdk/pull/1735

Honza
Assignee: nobody → odvarko
Attachment #8528447 - Flags: review?(zer0.kaos) → review?(zer0)
Attachment #8528447 - Attachment description: Patch (pull on github.com/mozilla/addon-sdk → Patch (pull on github.com/mozilla/addon-sdk)
Comment on attachment 8528447 [details] [review]
Patch (pull on github.com/mozilla/addon-sdk)

As we discussed face to face, the current API implementation has some issue with inheritance; we agreed on a different API that would solve that.

  MyTheme = Theme({
    // optional, used for `classList`
    name: 'my-theme',
    // mandatory, used to make `name` if `name` is not provided
    label: ‘My Theme’,
    // `styles` can accept as value `String`, `Style` or `Theme` instances,
    // or an array with those types.
    styles: [LightTheme, “./mytheme.css”]
  })
Attachment #8528447 - Flags: review?(zer0)
Flags: needinfo?(rFobic)
Patch updated (see the same pull request #1735)

Honza
Attachment #8528447 - Flags: review?(zer0.kaos)
Btw. I had to use:

self.data.url("theme.css")],

... relative path doesn't work on the platform.

Honza
(In reply to Jan Honza Odvarko [:Honza] from comment #20)
> Btw. I had to use:
> 
> self.data.url("theme.css")],
>
> ... relative path doesn't work on the platform.

In fact is something the API needs to implement on its side; like we have done for the rest of SDK APIs. You can take a look here to have an idea: https://github.com/mozilla/addon-sdk/blob/master/lib/sdk/stylesheet/style.js


> 
> Honza
Attachment #8528447 - Flags: review?(zer0.kaos) → review?(zer0)
> In fact is something the API needs to implement on its side;
Yep (should be done in a separate report though)

> You can take a look here to have an idea: https://github.com/mozilla/
> addon-sdk/blob/master/lib/sdk/stylesheet/style.js
I appended support for relative URLs to the current pull request.

Honza
@Matteo: what do you think about the latest changes? Does it look ok?
It would be great if we can land this in 37 (uplift in about a week)

Honza
Comment on attachment 8528447 [details] [review]
Patch (pull on github.com/mozilla/addon-sdk)

I apologize for the delay! Looks good to me, r+. However I'd like to have some unit test to be sure that the API is working as expected; especially for the methods `getStyles` and `getClassList` when we pass strings, arrays and themes. We could also implement the support for `Style` object but I don't think is a blocker, we can implement that in the future, especially if we're going to use more widely the `Style` object.
Attachment #8528447 - Flags: review?(zer0) → review+
Just a note, so this isn't forgotten. 
The patch needs to be merged into the Add-on master branch.

Honza
Flags: needinfo?(rFobic)
Honza could you please take a look at the pull request https://github.com/mozilla/addon-sdk/pull/1735 as far as I can see it fails tests, so we can't land it as is. Also if you'll take a look at the commits https://github.com/mozilla/addon-sdk/pull/1735/commits last commit introduced a test failurs. You can also follow the "details" link in the pull request to see test logs https://travis-ci.org/mozilla/addon-sdk/builds/44202574
Flags: needinfo?(rFobic)
Attached file failures.txt — 
I can't run tests locally to figure out what could cause the failure. There is an exception even if I am using pure mozilla/addon-sdk master clone, nightly and jpm updated

Trying to run:
npm test
(see the attachment for failures)

or

jpm test -v -b nightly -o <path-to-sdk-clone>
(see the bottom of this comment)

Any tips why the Travis is failing?

Honza


JPM error   Message: TypeError: this.docShell is null
  Stack:
    get_webProgress@chrome://global/content/bindings/browser.xml:398:1
addTab@chrome://browser/content/tabbrowser.xml:1763:13
openTab@file:///C:/Users/Honza/AppData/Local/Temp/f00065a5-e047-452c-829f-f9c4c3
503ec8/extensions/@addon-sdk/lib/toolkit/loader.js -> resource://extensions.modu
les.addon-sdk.commonjs.path./sdk/tabs/utils.js:143:16
open<@resource://extensions.modules.addon-sdk.commonjs.path./toolkit/loader.js -
> resource://addon-sdk/test/test-content-events.js:38:40
curry</currier/curried@file:///C:/Users/Honza/AppData/Local/Temp/f00065a5-e047-4
52c-829f-f9c4c3503ec8/extensions/@addon-sdk/lib/toolkit/loader.js -> resource://
extensions.modules.addon-sdk.commonjs.path./sdk/lang/functional/core.js:88:40
exports["test multiple tabs"]@resource://extensions.modules.addon-sdk.commonjs.p
ath./toolkit/loader.js -> resource://addon-sdk/test/test-content-events.js:59:18

@file:///C:/Users/Honza/AppData/Local/Temp/f00065a5-e047-452c-829f-f9c4c3503ec8/
extensions/@addon-sdk/lib/toolkit/loader.js -> resource://extensions.modules.add
on-sdk.commonjs.path./sdk/test.js:67:13
start@file:///C:/Users/Honza/AppData/Local/Temp/f00065a5-e047-452c-829f-f9c4c350
3ec8/extensions/@addon-sdk/lib/toolkit/loader.js -> resource://extensions.module
s.addon-sdk.commonjs.path./sdk/deprecated/unit-test.js:559:7
startMany/runNextTest/<@file:///C:/Users/Honza/AppData/Local/Temp/f00065a5-e047-
452c-829f-f9c4c3503ec8/extensions/@addon-sdk/lib/toolkit/loader.js -> resource:/
/extensions.modules.addon-sdk.commonjs.path./sdk/deprecated/unit-test.js:522:11
Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/m
odules/Promise-backend.js:870:23
this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://g
re/modules/Promise-backend.js:749:7
this.PromiseWalker.scheduleWalkerLoop/<@resource://gre/modules/Promise.jsm -> re
source://gre/modules/Promise-backend.js:691:37


JPM error JavaScript error: chrome://global/content/browser-child.js, line 586:
TypeError: initData[0] is null

JPM error JavaScript error: chrome://browser/content/browser.js, line 8569: Type
Error: aBrowser.currentURI is null

JPM info console.error: addon-sdk:

JPM info   fail:
  Timed out (after: START)

JPM info console.error: addon-sdk:

JPM info   fail:
  Should not be any unexpected tabs open

JPM info console.trace: addon-sdk:
_ecated/unit-test.js 108 fail
_ecated/unit-test.js 338 done/<
_/Promise-backend.js 870 Handler.prototype.process
_/Promise-backend.js 749 this.PromiseWalker.walkerLoop
_/Promise-backend.js 691 this.PromiseWalker.scheduleWalkerLoop/<
                     0


JPM info console.log: addon-sdk: Windows open:

JPM error *************************
A coding exception was thrown in a Promise resolution callback.
See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/Pr
omise


JPM info Full message: TypeError: tab.linkedBrowser.currentURI is null
Full stack: getURI@file:///C:/Users/Honza/AppData/Local/Temp/f00065a5-e047-452c-
829f-f9c4c3503ec8/extensions/@addon-sdk/lib/toolkit/loader.js -> resource://exte
nsions.modules.addon-sdk.commonjs.path./sdk/tabs/utils.js:182:3
done/<@file:///C:/Users/Honza/AppData/Local/Temp/f00065a5-e047-452c-829f-f9c4c35
03ec8/extensions/@addon-sdk/lib/toolkit/loader.js -> resource://extensions.modul
es.addon-sdk.commonjs.path./sdk/deprecated/unit-test.js:351:48
Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/m
odules/Promise-backend.js:870:23
this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://g
re/modules/Promise-backend.js:749:7
this.PromiseWalker.scheduleWalkerLoop/<@resource://gre/modules/Promise.jsm -> re
source://gre/modules/Promise-backend.js:691:37

*************************
console.error: addon-sdk:
  Message: TypeError: tab.linkedBrowser.currentURI is null
  Stack:
    getURI@file:///C:/Users/Honza/AppData/Local/Temp/f00065a5-e047-452c-829f-f9c
4c3503ec8/extensions/@addon-sdk/lib/toolkit/loader.js -> resource://extensions.m
odules.addon-sdk.commonjs.path./sdk/tabs/utils.js:182:3
done/<@file:///C:/Users/Honza/AppData/Local/Temp/f00065a5-e047-452c-829f-f9c4c35
03ec8/extensions/@addon-sdk/lib/toolkit/loader.js -> resource://extensions.modul
es.addon-sdk.commonjs.path./sdk/deprecated/unit-test.js:351:48
Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/m
odules/Promise-backend.js:870:23
this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://g
re/modules/Promise-backend.js:749:7
this.PromiseWalker.scheduleWalkerLoop/<@resource://gre/modules/Promise.jsm -> re
source://gre/modules/Promise-backend.js:691:37
Flags: needinfo?(rFobic)
The pull is fixed now:
https://github.com/mozilla/addon-sdk/pull/1735/commits

@Irakli, can you merge please?

Honza
@Irakli, is this forgotten?

Honza
Excellent, thanks!

Honza
Flags: needinfo?(rFobic)
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: