Closed
Bug 1057346
Opened 10 years ago
Closed 9 years ago
Devtools styling API
Categories
(Add-on SDK Graveyard :: General, defect, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla37
People
(Reporter: Honza, Assigned: Honza)
References
Details
Attachments
(2 files)
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
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(rFobic)
Comment 1•10 years ago
|
||
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)
Updated•10 years ago
|
Blocks: devtools-sdk
Assignee | ||
Comment 2•10 years ago
|
||
(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
Updated•10 years ago
|
Summary: Theme API → Devtools styling API
Comment 4•10 years ago
|
||
(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 ?
Assignee | ||
Comment 5•10 years ago
|
||
> 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
Comment 6•10 years ago
|
||
(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.
Comment 7•10 years ago
|
||
(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.
Assignee | ||
Comment 8•10 years ago
|
||
(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
Priority: -- → P1
Assignee | ||
Comment 9•10 years ago
|
||
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
Comment 10•10 years ago
|
||
(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.
Assignee | ||
Comment 11•10 years ago
|
||
(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
Comment 12•10 years ago
|
||
(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?
Assignee | ||
Comment 13•10 years ago
|
||
(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
Assignee | ||
Comment 14•10 years ago
|
||
I need some feedback, please see comment #9 Thanks Honza
Flags: needinfo?(zer0)
Flags: needinfo?(rFobic)
Comment 15•10 years ago
|
||
(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)
Assignee | ||
Updated•10 years ago
|
Target Milestone: --- → mozilla37
Assignee | ||
Comment 16•10 years ago
|
||
Pull request https://github.com/mozilla/addon-sdk/pull/1735 Honza
Assignee: nobody → odvarko
Assignee | ||
Comment 17•10 years ago
|
||
Attachment #8528447 -
Flags: review?(zer0.kaos)
Assignee | ||
Updated•10 years ago
|
Attachment #8528447 -
Flags: review?(zer0.kaos) → review?(zer0)
Assignee | ||
Updated•10 years ago
|
Attachment #8528447 -
Attachment description: Patch (pull on github.com/mozilla/addon-sdk → Patch (pull on github.com/mozilla/addon-sdk)
Comment 18•10 years ago
|
||
Comment on attachment 8528447 [details]
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)
Updated•10 years ago
|
Flags: needinfo?(rFobic)
Assignee | ||
Comment 19•10 years ago
|
||
Patch updated (see the same pull request #1735) Honza
Assignee | ||
Updated•10 years ago
|
Attachment #8528447 -
Flags: review?(zer0.kaos)
Assignee | ||
Comment 20•10 years ago
|
||
Btw. I had to use: self.data.url("theme.css")], ... relative path doesn't work on the platform. Honza
Comment 21•10 years ago
|
||
(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
Updated•10 years ago
|
Attachment #8528447 -
Flags: review?(zer0.kaos) → review?(zer0)
Assignee | ||
Comment 22•10 years ago
|
||
> 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
Assignee | ||
Comment 23•10 years ago
|
||
@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 24•10 years ago
|
||
Comment on attachment 8528447 [details]
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+
Assignee | ||
Comment 25•10 years ago
|
||
Just a note, so this isn't forgotten. The patch needs to be merged into the Add-on master branch. Honza
Flags: needinfo?(rFobic)
Comment 26•10 years ago
|
||
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)
Assignee | ||
Comment 27•10 years ago
|
||
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
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(rFobic)
Assignee | ||
Comment 28•10 years ago
|
||
The pull is fixed now: https://github.com/mozilla/addon-sdk/pull/1735/commits @Irakli, can you merge please? Honza
Assignee | ||
Comment 29•10 years ago
|
||
@Irakli, is this forgotten? Honza
Comment 30•10 years ago
|
||
Commits pushed to master at https://github.com/mozilla/addon-sdk https://github.com/mozilla/addon-sdk/commit/18151ff247e9deab6699c2349283f43bbcf945a7 Bug 1057346 - Devtools styling API https://github.com/mozilla/addon-sdk/commit/a9dd3c77f5d2721d26f7b869a19e5e153f74c92b Bug 1057346 - Devtools styling API (2) https://github.com/mozilla/addon-sdk/commit/fca2f57733f801e94f63a3b3962ad8c4fced07ed Bug 1057346 - Support for relative style URL https://github.com/mozilla/addon-sdk/commit/7caca5b489c113ba64cb7544707d9b63dea1856d Bug 1057346 - Remove helper script https://github.com/mozilla/addon-sdk/commit/09622601d37a80b3b5002138f920b901d0596cfc Merge remote-tracking branch 'upstream/master' into bug1057346 https://github.com/mozilla/addon-sdk/commit/a5de61fc69beb66b543a23d98d2131f80ddffca6 Bug 1057346 - Properly convert single (string) relative URL https://github.com/mozilla/addon-sdk/commit/d78a154d0a91f6e594a82358724e48b0e6d8b2c1 Merge remote-tracking branch 'upstream/master' into bug1057346 https://github.com/mozilla/addon-sdk/commit/eca2c4c068a017a2e90dc295f0fc9de45ca4f655 Merge pull request #1735 from janodvarko/bug1057346 Bug 1057346 - Devtools styling API r=@gozala
Assignee | ||
Comment 31•10 years ago
|
||
Excellent, thanks! Honza
Updated•10 years ago
|
Flags: needinfo?(rFobic)
Updated•9 years ago
|
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.
Description
•