J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Reporter
	Description • 10 years ago

To assist launching WebIDE quickly, we could add a Australis-style button for WebIDE that users can place in their top toolbar via the Customize mode.

It's possible to place the root Developer menu there today, but perhaps people would like access to a specific tool to save a click.

	Paul Rouget [:paul] Assignee
	Comment 1 • 10 years ago

(In reply to J. Ryan Stinnett [:jryans] from comment #0)
> To assist launching WebIDE quickly, we could add a Australis-style button
> for WebIDE that users can place in their top toolbar via the Customize mode.
> 
> It's possible to place the root Developer menu there today, but perhaps
> people would like access to a specific tool to save a click.

Yep. We would disable this button by default, and make it available only once WebIDE has been opened once.

	Paul Rouget [:paul] Assignee
	Comment 3 • 10 years ago

Jared, we want to add a widget (button) for WebIDE in Firefox' toolbar. We don't want this widget to be accessible until the user has used WebIDE at least once. In this patch, I use a simple pref to know if the widget should be added or not.

But Firefox needs to be restarted for the change to be taken into account. Can we force a "refresh" of the customization UI? Or should we add the button in the default set, and dynamically toggle the hidden attribute? I'm not sure what's the right approach is.

	Jared Wein [:jaws] (please needinfo? me)
	Comment 4 • 10 years ago

Firefox doesn't need to be restarted to add a button to the toolbar :)

What you can do is when WebIDE is launched, call CustomizableUI.addToToolbar() with the widget name. That should take care of adding it to the toolbar and the placement will be persisted. This is the same code that is run when right-clicking on a button in the Firefox menu and choosing "Move to Toolbar".

Before WebIDE is launched, you can have the button located in the customization palette, which could be another form of discovery for people.

Hope that helps :)

	Jared Wein [:jaws] (please needinfo? me)
	Comment 5 • 10 years ago

CustomizableUI.addWidgetToArea(aNode.id, CustomizableUI.AREA_NAVBAR); is the actual function.

	Jared Wein [:jaws] (please needinfo? me)
	Comment 6 • 10 years ago

Calling `gCustomizeMode.addToToolbar(aNode);` may actually be preferred since that will also dispatch the "customizationchange" event that add-ons or other code may be listening for.

	Jared Wein [:jaws] (please needinfo? me)
	Comment 7 • 10 years ago

Comment on attachment 8477259 [details] [diff] [review]
v0.1

Review of attachment 8477259 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/components/customizableui/CustomizableWidgets.jsm
@@ +985,5 @@
> +  CustomizableWidgets.push({
> +    id: "webide-button",
> +    label: "webide",
> +    tooltiptext: "webide tooltip",
> +    defaultArea: CustomizableUI.AREA_PANEL,

If you don't define a defaultArea then it should be placed in the palette by default, which seems fine to me.

::: browser/themes/shared/menupanel.inc.css
@@ +89,5 @@
>  }
>  
> +#webide-button[cui-areatype="menu-panel"],
> +toolbarpaletteitem[place="palette"] > #webide-button {
> +  -moz-image-region: rect(0px, 512px, 32px, 480px);

You'll also need HiDPI icons here too, for both the menupanel and the toolbarbutton.

	Paul Rouget [:paul] Assignee
	Comment 8 • 10 years ago

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #4)
> Firefox doesn't need to be restarted to add a button to the toolbar :)

Sorry, I was unclear. We don't want a lambda user to have access to the WebIDE button. So by default, we don't want the button to be present in the palette at all. When the user clicks "customize", he won't see the WebIDE button anywhere.

But once the user starts WebIDE once, then the button is available in the palette, even maybe directly placed in the toolbar.

Makes sense?

	Jared Wein [:jaws] (please needinfo? me)
	Comment 9 • 10 years ago

Yeah, you could keep most of this current patch and then add some code that gets run when the pref initially gets set to true to add the button at runtime using CustomizableUI.createWidget[1].

[1] https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/CustomizableUI.jsm#createWidget%28%29

But is there a way for the user to "delete" this button? Is that a problem? Or are you OK with people removing this button from their toolbar, and it living "forever" in the paletter? I don't see an issue with the button living forever in the palette if it's not wanted, since it also allows people to add it back to their toolbar when they want, but I just wanted to make sure you are OK with this.

	Paul Rouget [:paul] Assignee
	Comment 10 • 10 years ago

How's that?

Need some tests and an actual icon.

	Jared Wein [:jaws] (please needinfo? me)
	Comment 11 • 10 years ago

Comment on attachment 8478430 [details] [diff] [review]
v0.9

Review of attachment 8478430 [details] [diff] [review]:
-----------------------------------------------------------------

Yeah, this seems in the right direction. You'll also need to have a HiDPI icon on OSX (we don't have them for Windows or Linux yet).

	Paul Rouget [:paul] Assignee
	Comment 12 • 10 years ago

Darrin, we need an icon for WebIDE. Can you help?

	Stephen Horlander [:shorlander]
	Comment 13 • 10 years ago

Do you want this added to the existing Toolbar.png and menuPanel.png sprites?

	Paul Rouget [:paul] Assignee
	Comment 14 • 10 years ago

(In reply to Stephen Horlander [:shorlander] from comment #13)
> Do you want this added to the existing Toolbar.png and menuPanel.png sprites?

I think so.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Reporter
	Comment 15 • 10 years ago

Stephen, any updates here?

	Paul Rouget [:paul] Assignee
	Comment 18 • 10 years ago

Jaws, we need to land these strings even though the patch is not ready yet (still waiting on UX). We want to land that before the next uplift, in preparation of the fx devtools edition.

	Joe Walker [:jwalker]
	Comment 19 • 10 years ago

Comment on attachment 8503026 [details] [diff] [review]
strings

Manager drive-by, sorry want to be sure this gets in for the merge

	Francesco Lodolo [:flod]
	Comment 20 • 10 years ago

Comment on attachment 8503026 [details] [diff] [review]
strings

Review of attachment 8503026 [details] [diff] [review]:
-----------------------------------------------------------------

String-wise this looks good to me.

	Paul Rouget [:paul] Assignee
	Comment 21 • 10 years ago

https://hg.mozilla.org/integration/fx-team/rev/603ee6edc6ca

	Paul Rouget [:paul] Assignee
	Comment 22 • 10 years ago

landed to central too: https://hg.mozilla.org/mozilla-central/rev/cec1a116c4f9

	Tim Taubert [:ttaubert] (inactive)
	Comment 23 • 10 years ago

https://hg.mozilla.org/mozilla-central/rev/603ee6edc6ca

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Reporter
	Comment 24 • 10 years ago

Previous changeset only contained strings to land ahead of time.

	Paul Rouget [:paul] Assignee
	Comment 25 • 10 years ago

There's something I don't understand about how widgets work.

Even though there's no visible widget, CustomizableUI.getWidget("webide-button") doesn't return null. And it says there's one instance of the widget. Even after a restart. Even if I comment out the code that installs the widget.

So there must be some sort of cache.

I use CustomizableUI.removeWidgetFromArea("webide-button") and CustomizableUI.destroyWidget("webide-button") to uninstall the widget. But I guess this is not enough.

Halp!

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Reporter
	Comment 26 • 10 years ago

Paul, as far as how this functions, I would think we might do:

* Regular Edition: Button appears in Customize mode like any other item
  * I don't think we need to wait for someone to first open WebIDE before the button appears here, just show it all the time, like the Developer menu today
* Dev Edition: Button is in main toolbar already from first-run
  * This part could happen either here, or I filed bug 1073915 about it a while back

What do you think?

	Paul Rouget [:paul] Assignee
	Comment 27 • 10 years ago

(In reply to J. Ryan Stinnett [:jryans] from comment #26)
> Paul, as far as how this functions, I would think we might do:
> 
> * Regular Edition: Button appears in Customize mode like any other item
>   * I don't think we need to wait for someone to first open WebIDE before
> the button appears here, just show it all the time, like the Developer menu
> today

We gonna need an approval for that.

> * Dev Edition: Button is in main toolbar already from first-run
>   * This part could happen either here, or I filed bug 1073915 about it a
> while back

Yes.

	Paul Rouget [:paul] Assignee
	Comment 28 • 10 years ago

(In reply to J. Ryan Stinnett [:jryans] from comment #26)
> Paul, as far as how this functions, I would think we might do:
> 
> * Regular Edition: Button appears in Customize mode like any other item
>   * I don't think we need to wait for someone to first open WebIDE before
> the button appears here, just show it all the time, like the Developer menu
> today

Dave, Joe, what do you guys think?

	Joe Walker [:jwalker]
	Comment 29 • 10 years ago

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #28)
> (In reply to J. Ryan Stinnett [:jryans] from comment #26)
> > Paul, as far as how this functions, I would think we might do:
> > 
> > * Regular Edition: Button appears in Customize mode like any other item
> >   * I don't think we need to wait for someone to first open WebIDE before
> > the button appears here, just show it all the time, like the Developer menu
> > today
> 
> Dave, Joe, what do you guys think?

I guess that the browser team will want to wait for the dust to clear on devedition, and may then want to tone down the developer influence on regular.
In short: not my call, not the time to call.

	Jared Wein [:jaws] (please needinfo? me)
	Comment 30 • 10 years ago

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #25)
> There's something I don't understand about how widgets work.
> 
> Even though there's no visible widget,
> CustomizableUI.getWidget("webide-button") doesn't return null. And it says
> there's one instance of the widget. Even after a restart. Even if I comment
> out the code that installs the widget.
> 
> So there must be some sort of cache.

There is an in-memory cache for API widgets, that it gets removed from when destroyWidget is called. In that instance, then calling getWidget will return null.

> I use CustomizableUI.removeWidgetFromArea("webide-button") and
> CustomizableUI.destroyWidget("webide-button") to uninstall the widget. But I
> guess this is not enough.

When a widget isn't known, we assume that it is a XUL widget and therefore we unfortunately have to assume that it exists as it may be *about* to exist through some add-on. See http://mxr.mozilla.org/mozilla-central/source/browser/components/customizableui/CustomizableUI.jsm#701 for where this comes from.

Due to this, if you want to see if a widget exists, you should do the following:
let wrapper = CustomizableUI.getWidget("widget-id");
let widget = wrapper.forWindow(window);
let exists = !!widget.node;

The `node` property of the widget is the only reliable way to determine if the widget actually exists for this window. You'll note that if you call getWidget for a widgetId that doesn't exist, then the `provider` is listed as XUL.

In the above sample code, `exists` will also evaluate to `true` if the widget exists but is located in the palette.

	Paul Rouget [:paul] Assignee
	Comment 31 • 10 years ago

Clearing needinfo. Stephen is working on icons, and we won't show webide widget by default.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Reporter
	Comment 32 • 10 years ago

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #31)
> we won't show webide widget by default.

Can you be more specific here?  Will it also be hidden on Dev Edition too, or do you just mean non-Dev Edition?  I am asking since there is currently an expectation that it will be highlighted during first run in the main toolbar: bug 1078454.

	Paul Rouget [:paul] Assignee
	Comment 33 • 10 years ago

(In reply to J. Ryan Stinnett [:jryans] from comment #32)
> (In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from
> comment #31)
> > we won't show webide widget by default.
> 
> Can you be more specific here?  Will it also be hidden on Dev Edition too,
> or do you just mean non-Dev Edition?  I am asking since there is currently
> an expectation that it will be highlighted during first run in the main
> toolbar: bug 1078454.

In non-Dev Edition: no WebIDE icon anywhere. Will show-up only once WebIDE is used at least once.
In Dev Edition: visible by default in toolbar.

	Paul Rouget [:paul] Assignee
	Comment 34 • 10 years ago

Alright, so I tried this:

> let exist = widgetWrapper && widgetWrapper.instances.some(i => !!i.node)

Which is `false` after I call `CustomizableUI.destroyWidget`.

Bug right after I call `CustomizableUI.createWidget`, it's still false.

I'm thinking of exposing `CustomizableUIInternal.widgetExists` to `CustomizableUI`.

	Paul Rouget [:paul] Assignee
	Comment 35 • 10 years ago

Well, CustomizableUIInternal.widgetExists() returns true at startup.

	Paul Rouget [:paul] Assignee
	Comment 36 • 10 years ago

I figured it out.

	Paul Rouget [:paul] Assignee
	Comment 37 • 10 years ago

Still need an icon and tests

	Stephen Horlander [:shorlander]
	Comment 39 • 10 years ago

Toolbar and menuPanel sprite sheets with WebIDE icon.

	Paul Rouget [:paul] Assignee
	Comment 40 • 10 years ago

Jaws, can you review this patch?

A couple of things to know. The new widget is controlled by 3 preferences:

"devtools.webide.widget.autoinstall": whether we auto install the WebIDE widget when WebIDE starts or not

"devtools.webide.widget.enabled": control the installation status of the WebIDE widget. The fact this pref ends with ".enabled" is important as gDevTools.updateCommandAvailability() is triggered everytime a devtools.*.enabled perf changes.

"devtools.webide.widget.inToolbarByDefault": when the widget is installed, we move it in the toolbar. But we don't want it to be its default position. The user can click "Restore Defaults", and then the widget goes away (back customize panel, next to "Tab Group"). But for the Developer Edition, we actually want the toolbar to be the default position. This is what this pref controls. But it doesn't work. Apparently, using defaultArea doesn't work as I expect it to. So I need some help for this.

	Paul Rouget [:paul] Assignee
	Comment 41 • 10 years ago

Fixed coordinate on osx.

	Jared Wein [:jaws] (please needinfo? me)
	Comment 42 • 10 years ago

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #40)
> "devtools.webide.widget.inToolbarByDefault": when the widget is installed,
> we move it in the toolbar. But we don't want it to be its default position.
> The user can click "Restore Defaults", and then the widget goes away (back
> customize panel, next to "Tab Group"). But for the Developer Edition, we
> actually want the toolbar to be the default position. This is what this pref
> controls. But it doesn't work. Apparently, using defaultArea doesn't work as
> I expect it to. So I need some help for this.

Right, this is because we can't allow add-ons to specify that their default area is the toolbar and then rely on that for Restore Defaults (it would break Restore Defaults). This means you also have to update http://mxr.mozilla.org/mozilla-central/source/browser/components/customizableui/CustomizableUI.jsm#205

So defaultArea says where the widget should go when it is installed, but defaultPlacements (linked to in the previous paragraph) is where items should go when Restore Defaults is used.

	Jared Wein [:jaws] (please needinfo? me)
	Comment 43 • 10 years ago

Comment on attachment 8510266 [details] [diff] [review]
v2.1

Review of attachment 8510266 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/devtools/webide/test/browser_widget.js
@@ +6,5 @@
> +  waitForExplicitFinish();
> +  Task.spawn(function() {
> +    let win = yield openWebIDE();
> +    ok(document.querySelector("#webide-button"), "Found WebIDE button");
> +    Services.prefs.setBoolPref("devtools.webide.widget.enabled", false);

There should be a registerCleanupFunction that clears this user pref change.

::: browser/locales/en-US/chrome/browser/customizableui/customizableWidgets.properties
@@ +117,2 @@
>  devtools-webide-button.label = WebIDE
> +devtools-webide-button.tooltiptext2 = Open WebIDE (%S)

This should be devtools-webide-button2.tooltiptext and the devtools-webide-button.label should be updated to devtools-webide-button2.label. This is documented at https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Localization_best_practices#Updating_Entity_Names

	Paul Rouget [:paul] Assignee
	Comment 44 • 10 years ago

https://tbpl.mozilla.org/?tree=Try&rev=d96142bec352

	Jared Wein [:jaws] (please needinfo? me)
	Comment 45 • 10 years ago

Comment on attachment 8512533 [details] [diff] [review]
v2.2

Review of attachment 8512533 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/devtools/webide/test/browser_widget.js
@@ +9,5 @@
> +    ok(document.querySelector("#webide-button"), "Found WebIDE button");
> +    Services.prefs.setBoolPref("devtools.webide.widget.enabled", false);
> +    ok(!document.querySelector("#webide-button"), "WebIDE button uninstalled");
> +    yield closeWebIDE(win);
> +    Services.prefs.clearUserPref("devtools.webide.widget.enabled");

This should still be moved to a registerCleanupFunction in case the test bails out before it reaches this line. In that scenario, further tests will be influenced by the value of the pref.

This can be written as:

```js
function test() {
  const kWebIDEEnabledPref = "devtools.webide.widget.enabled";
  waitForExplicitFinish();
  registerCleanupFunction(function() {
    Services.prefs.clearUserPref(kWebIDEEnabledPref);
  });
  Task.spawn(function() {
    let win = yield openWebIDE();
    ok(document.querySelector("#webide-button"), "Found WebIDE button");
    Services.prefs.setBoolPref(kWebIDEEnabledPref, false);
    ok(!document.querySelector("#webide-button"), "WebIDE button removed");
    yield closeWebIDE(win);
  }).then(finish, handleError);
}
```

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Reporter
	Comment 46 • 10 years ago

Comment on attachment 8512533 [details] [diff] [review]
v2.2

Review of attachment 8512533 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/devtools/framework/gDevTools.jsm
@@ +725,5 @@
> +
> +  /**
> +   * Move WebIDE widget to the main toolbar
> +   */
> +  showWebIDEWidget: function() {

The function name does make it clear that it means "move to main toolbar / navbar".

::: browser/devtools/webide/content/webide.js
@@ +91,5 @@
>  
> +    if (Services.prefs.getBoolPref("devtools.webide.widget.autoinstall") &&
> +        !Services.prefs.getBoolPref("devtools.webide.widget.enabled")) {
> +      Services.prefs.setBoolPref("devtools.webide.widget.enabled", true);
> +      gDevToolsBrowser.showWebIDEWidget();

Doesn't this mean it moves to main toolbar / nav on WebIDE open?

I thought that was for Dev Edition only, but autoinstall is set true by default.

Don't you want |installWebIDEWidget| here?

	Paul Rouget [:paul] Assignee
	Comment 47 • 10 years ago

(In reply to J. Ryan Stinnett [:jryans] from comment #46)
> Comment on attachment 8512533 [details] [diff] [review]
> v2.2
> 
> Review of attachment 8512533 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: browser/devtools/framework/gDevTools.jsm
> @@ +725,5 @@
> > +
> > +  /**
> > +   * Move WebIDE widget to the main toolbar
> > +   */
> > +  showWebIDEWidget: function() {
> 
> The function name does make it clear that it means "move to main toolbar /
> navbar".

I'll rename it.

> 
> ::: browser/devtools/webide/content/webide.js
> @@ +91,5 @@
> >  
> > +    if (Services.prefs.getBoolPref("devtools.webide.widget.autoinstall") &&
> > +        !Services.prefs.getBoolPref("devtools.webide.widget.enabled")) {
> > +      Services.prefs.setBoolPref("devtools.webide.widget.enabled", true);
> > +      gDevToolsBrowser.showWebIDEWidget();
> 
> Doesn't this mean it moves to main toolbar / nav on WebIDE open?

Yes.

> I thought that was for Dev Edition only, but autoinstall is set true by
> default.

No.

default position == where it goes after the user clicks "Restore Defaults"

Dev Edition:
- installed even if webide hasn't been started yet
- default position is the toolbar

Vanilla Firefox:
- not installed until WebIDE has run at least once
- default position is the customize panel, but after webide firstrun, it's moved into the toolbar

This patch is for vanilla version. For devedition, we will set:
> pref("devtools.webide.widget.enabled", false);
> pref("devtools.webide.widget.inNavbarByDefault", false);

to true.

> Don't you want |installWebIDEWidget| here?

No. Setting the pref triggers installWebIDEWidget.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Reporter
	Comment 48 • 10 years ago

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #47)
> default position == where it goes after the user clicks "Restore Defaults"
> 
> Dev Edition:
> - installed even if webide hasn't been started yet
> - default position is the toolbar
> 
> Vanilla Firefox:
> - not installed until WebIDE has run at least once

So, you open WebIDE, and the widget is installed...

> - default position is the customize panel, but after webide firstrun, it's
> moved into the toolbar

...and also goes immediately to the main toolbar.  Is this intended?  There is no apparent difference between "WebIDE has run at least once" and "after WebIDE first run", so both of these steps happen at same time.

So, currently, both Dev Edition and vanilla Firefox will put WebIDE in the main toolbar.  The only difference is that Dev Edition is there from the first run of the browser, while vanilla Firefox waits until WebIDE open.

I had assumed that for vanilla Firefox, it would only appear in Customize mode or some panel, not the main toolbar (after running WebIDE), but maybe that is my confusion.  I do not have strong feelings either way, but let me know if my description of the current behavior agrees with what you intend to have happen here.

	Paul Rouget [:paul] Assignee
	Comment 49 • 10 years ago

(In reply to J. Ryan Stinnett [:jryans] from comment #48)
> (In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from
> comment #47)
> > default position == where it goes after the user clicks "Restore Defaults"
> > 
> > Dev Edition:
> > - installed even if webide hasn't been started yet
> > - default position is the toolbar
> > 
> > Vanilla Firefox:
> > - not installed until WebIDE has run at least once
> 
> So, you open WebIDE, and the widget is installed...
> 
> > - default position is the customize panel, but after webide firstrun, it's
> > moved into the toolbar
> 
> ...and also goes immediately to the main toolbar.  Is this intended?

Yes.

> There
> is no apparent difference between "WebIDE has run at least once" and "after
> WebIDE first run", so both of these steps happen at same time.
> 
> So, currently, both Dev Edition and vanilla Firefox will put WebIDE in the
> main toolbar.

Yes.

> The only difference is that Dev Edition is there from the
> first run of the browser

Yes.

> while vanilla Firefox waits until WebIDE open.

And also, "restore defaults" in vanilla move the button in the customize panel. In devedition, move it to the toolbar (if it moved).

> I had assumed that for vanilla Firefox, it would only appear in Customize
> mode or some panel, not the main toolbar (after running WebIDE), but maybe
> that is my confusion.  I do not have strong feelings either way, but let me
> know if my description of the current behavior agrees with what you intend
> to have happen here.

Yep. Can you re-review?

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Reporter
	Comment 50 • 10 years ago

Comment on attachment 8512533 [details] [diff] [review]
v2.2

Review of attachment 8512533 [details] [diff] [review]:
-----------------------------------------------------------------

Okay, seems good to me then.

r+, but please update the method name as discussed.

	Paul Rouget [:paul] Assignee
	Comment 52 • 10 years ago

I had to update the PNGs because WebIDE icons have already been introduced for the toolbars in bug 1088712.

	Paul Rouget [:paul] Assignee
	Comment 53 • 10 years ago

https://tbpl.mozilla.org/?tree=Try&rev=e63f90655b83

	Paul Rouget [:paul] Assignee
	Comment 55 • 10 years ago

Tested on all the platforms. It works. I haven't tested on a non-retina mac thought.

	Paul Rouget [:paul] Assignee
	Comment 56 • 10 years ago

https://hg.mozilla.org/integration/fx-team/rev/fbe6dcd6b14a

	Paul Rouget [:paul] Assignee
	Comment 57 • 10 years ago

Approval Request Comment
[Feature/regressing bug #]: dev edition
[User impact if declined]: no webide button
[Describe test coverage new/current, TBPL]: in fx-team: https://tbpl.mozilla.org/?tree=Fx-Team&rev=fbe6dcd6b14a
[Risks and why]: medium. impact the navbar.
[String/UUID change made/needed]: no string changes.

	Paul Rouget [:paul] Assignee
	Comment 58 • 10 years ago

This can't land on Aurora with bug 1088712 being uplifted.

	Paul Rouget [:paul] Assignee
	Comment 59 • 10 years ago

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #58)
> This can't land on Aurora with bug 1088712 being uplifted.

I meant 'without'.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow) Reporter
	Comment 60 • 10 years ago

https://hg.mozilla.org/integration/fx-team/rev/fbe6dcd6b14a

	Carsten Book [:Tomcat]
	Comment 61 • 10 years ago

https://hg.mozilla.org/mozilla-central/rev/fbe6dcd6b14a

	Ryan VanderMeulen [:RyanVM]
	Comment 62 • 10 years ago

https://hg.mozilla.org/releases/mozilla-aurora/rev/79bded538654

	Vasilica Tamas, QA [:vtamas]
	Comment 63 • 10 years ago

I confirm that WebIDE icon is set:

 - by default in toolbar on Latest Firefox 36.0a2 (2014-12-08)
 - in toolbar after the first opening on Firefox 35 Beta 1 (20141201162954) and Latest Firefox 37.0a1 (2014-12-08)

Verified on Windows 7 x64, Ubuntu 14.04 x86 and Mac Osx 10.10.