Add WebIDE launch button

VERIFIED FIXED in Firefox 35

Status

()

Firefox
Developer Tools: WebIDE
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: jryans, Assigned: paul)

Tracking

unspecified
Firefox 36
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify +

Firefox Tracking Flags

(firefox35 verified, firefox36 verified)

Details

Attachments

(4 attachments, 9 obsolete attachments)

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.
(Assignee)

Comment 1

4 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.
(Assignee)

Comment 2

4 years ago
Created attachment 8477259 [details] [diff] [review]
v0.1
(Assignee)

Comment 3

4 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.
Flags: needinfo?(jaws)
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 :)
Flags: needinfo?(jaws)
CustomizableUI.addWidgetToArea(aNode.id, CustomizableUI.AREA_NAVBAR); is the actual function.
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.
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.
(Assignee)

Comment 8

4 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?
(Assignee)

Updated

4 years ago
Flags: needinfo?(jaws)
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.
Flags: needinfo?(jaws)
(Assignee)

Comment 10

4 years ago
Created attachment 8478430 [details] [diff] [review]
v0.9

How's that?

Need some tests and an actual icon.
Assignee: nobody → paul
Attachment #8477259 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8478430 - Flags: feedback?(jaws)
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).
Attachment #8478430 - Flags: feedback?(jaws) → feedback+
(Assignee)

Comment 12

4 years ago
Darrin, we need an icon for WebIDE. Can you help?
Flags: needinfo?(dhenein)
(Assignee)

Updated

4 years ago
Whiteboard: [blocked on UX]
Flags: needinfo?(dhenein) → needinfo?(shorlander)
Do you want this added to the existing Toolbar.png and menuPanel.png sprites?
Flags: needinfo?(shorlander)
(Assignee)

Comment 14

4 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.
(Reporter)

Updated

4 years ago
Blocks: 1054353
(Reporter)

Updated

4 years ago
Blocks: 1073915
Stephen, any updates here?
Flags: needinfo?(shorlander)
(Assignee)

Comment 16

4 years ago
Created attachment 8503025 [details] [diff] [review]
v0.99
Attachment #8478430 - Attachment is obsolete: true
(Assignee)

Comment 17

4 years ago
Created attachment 8503026 [details] [diff] [review]
strings
Attachment #8503026 - Flags: review?(jaws)
(Assignee)

Comment 18

4 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.
Comment on attachment 8503026 [details] [diff] [review]
strings

Manager drive-by, sorry want to be sure this gets in for the merge
Attachment #8503026 - Flags: review?(jaws) → review?(francesco.lodolo)
Comment on attachment 8503026 [details] [diff] [review]
strings

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

String-wise this looks good to me.
Attachment #8503026 - Flags: review?(francesco.lodolo) → review+
https://hg.mozilla.org/mozilla-central/rev/603ee6edc6ca
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 35
Previous changeset only contained strings to land ahead of time.
Status: RESOLVED → REOPENED
Keywords: leave-open
Resolution: FIXED → ---
(Reporter)

Updated

4 years ago
Attachment #8503026 - Flags: checkin+
(Assignee)

Comment 25

4 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!
Flags: needinfo?(jaws)
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?
(Assignee)

Comment 27

4 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.
(Assignee)

Comment 28

4 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?
Flags: needinfo?(jwalker)
Flags: needinfo?(dcamp)
(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.
Flags: needinfo?(jwalker)
(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.
Flags: needinfo?(jaws)
(Assignee)

Comment 31

4 years ago
Clearing needinfo. Stephen is working on icons, and we won't show webide widget by default.
Flags: needinfo?(shorlander)
Flags: needinfo?(dcamp)
(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.
Flags: needinfo?(paul)
(Assignee)

Comment 33

4 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.
Flags: needinfo?(paul)
(Assignee)

Comment 34

4 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`.
Flags: needinfo?(jaws)
(Assignee)

Comment 35

4 years ago
Well, CustomizableUIInternal.widgetExists() returns true at startup.
(Assignee)

Comment 36

4 years ago
I figured it out.
Flags: needinfo?(jaws)
(Assignee)

Comment 37

4 years ago
Created attachment 8507798 [details] [diff] [review]
v1

Still need an icon and tests
Attachment #8503025 - Attachment is obsolete: true
(Assignee)

Comment 38

4 years ago
Created attachment 8507799 [details] [diff] [review]
Aurora addendum
Created attachment 8509652 [details]
WebIDE-Icons.zip - 01

Toolbar and menuPanel sprite sheets with WebIDE icon.
(Assignee)

Comment 40

4 years ago
Created attachment 8510159 [details] [diff] [review]
v2

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.
Attachment #8507798 - Attachment is obsolete: true
Attachment #8510159 - Flags: review?(jaws)
(Assignee)

Comment 41

4 years ago
Created attachment 8510266 [details] [diff] [review]
v2.1

Fixed coordinate on osx.
(Assignee)

Updated

4 years ago
Whiteboard: [blocked on UX]
(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.
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
Attachment #8510266 - Flags: review+
Attachment #8510159 - Attachment is obsolete: true
Attachment #8510159 - Flags: review?(jaws)
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);
}
```
Attachment #8512533 - Flags: review?(jaws) → review+
(Assignee)

Updated

4 years ago
Attachment #8512533 - Flags: review?(jryans)
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?
Attachment #8512533 - Flags: review?(jryans)
(Assignee)

Comment 47

4 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.
(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.
Flags: needinfo?(paul)
(Assignee)

Comment 49

4 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?
Flags: needinfo?(paul)
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.
Attachment #8512533 - Flags: review+
(Assignee)

Comment 51

4 years ago
Created attachment 8513625 [details] [diff] [review]
v2.3 (r=jryans,r=jaws)
Attachment #8513625 - Flags: review+
(Assignee)

Comment 52

4 years ago
Created attachment 8513697 [details] [diff] [review]
v2.4 (r=jryans,r=jaws)

I had to update the PNGs because WebIDE icons have already been introduced for the toolbars in bug 1088712.
Attachment #8512533 - Attachment is obsolete: true
Attachment #8513625 - Attachment is obsolete: true
Attachment #8513697 - Flags: review+
(Reporter)

Updated

4 years ago
Duplicate of this bug: 1073915
(Assignee)

Comment 55

4 years ago
Tested on all the platforms. It works. I haven't tested on a non-retina mac thought.
(Assignee)

Comment 57

4 years ago
Created attachment 8514090 [details] [diff] [review]
v2.4 - aurora

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.
Attachment #8507799 - Attachment is obsolete: true
Attachment #8514090 - Flags: approval-mozilla-aurora?
(Assignee)

Comment 58

4 years ago
This can't land on Aurora with bug 1088712 being uplifted.
Depends on: 1088712
(Assignee)

Comment 59

4 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'.
https://hg.mozilla.org/mozilla-central/rev/fbe6dcd6b14a
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Attachment #8514090 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/79bded538654
status-firefox35: --- → fixed
status-firefox36: --- → fixed
Target Milestone: Firefox 35 → Firefox 36
Depends on: 1093198
Flags: qe-verify+
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.
Status: RESOLVED → VERIFIED
status-firefox35: fixed → verified
status-firefox36: fixed → verified
You need to log in before you can comment on or make changes to this bug.