607048 - Icons cannot be removed from the add-ons bar

Status: RESOLVED WONTFIX

(Firefox :: Toolbars and Customization, defect)

Description

[(no longer active)]

STR:

1. Update to the latest nightly and install Firebug.
2. Right click on the add-ons bar and click Customize.
3. Try to drag the Firebug icon away from the add-ons bar.  It doesn't work.
4. Drag a normal toolbar icon to this add-ons bar.
5. Try to drag that button away.  It doesn't work either.

Comment 1

[Dietrich Ayala (:dietrich)]

This sounds like a regression post-landing of add-on bar, since I did this a few thousand times a day when making that patch.

Comment 2

[Dietrich Ayala (:dietrich)]

Ah ok, so it's quite likely that Firebug is using the statusbar shim, which means it's not customizable. I'll try to take a look and see.

If that's the case, this is a problem with the add-on.

OR.. we could remove the shim, forcing add-ons that use the statusbar to update to the add-on bar (something the Firebug people are vehemently against).

OR.. we could make the statusbar shim itself a customizable toolbaritem. This might be the easiest way forward, that pleases the most people.

Comment 3

[(no longer active)]

(In reply to comment #2)
> OR.. we could make the statusbar shim itself a customizable toolbaritem. This
> might be the easiest way forward, that pleases the most people.

This seems like the best thing to do to me too!

Comment 4

[Dietrich Ayala (:dietrich)]

Attachment: wip

Comment 5

[flying sheep]

regarding dietrich’s options:

turn the temporary hack into a customizable widget: bug 599229
remove the hack asap: bug 598929

that means we’ll do both, most likely in this chronological order, so the firebug people will have to bite the bullet one day, anyway.

Comment 6

[flying sheep]

only: the information „the Firebug people [would be] vehemently against“ removing the compatibility hack was wrong.

you can read about their opinions e.g. here: http://code.google.com/p/fbug/issues/detail?id=3556 and in the comments to the bugs they merged into this one.

as soon as bug 598923 is fixed and there is a reliable way to add a similar button in the “bar down there” for both 3.6 and 4.0, they are not against removing temporary compatibility hacks, i think.

Comment 7

[Dietrich Ayala (:dietrich)]

Removing the compat shim is not the question for this bug. Please keep that discussion in bug 598929.

Comment 8

[flying sheep]

you were the one who said this would be one of the possible solutions. i just corrected one of your statements since it conveyed a wrong picture about the firebug devs and i provided links to the bugs you mentioned.

Comment 9

[Dietrich Ayala (:dietrich)]

That statement was derived from conversations with Firebug dev John. However, that's awesome if it's not a concern anymore!

I think we're going to make this change regardless, and once the add-on bar work is closer to complete (still a lot needs done) make the decision about the shim.

Comment 10

[Dietrich Ayala (:dietrich)]

No test because I'm not sure what exactly to test other than that the DOM structure is still what we change it to, or that a toolbaritem should behave like a toolbaritem does.

Comment 12

[Dão Gottwald [:dao]]

Comment on attachment 487389 [details] [diff] [review]
wip

As discussed some time ago in the newsgroups, this would break add-ons putting items here, as their formerly permanent items would be able to disappear from the document.

You might also get a race condition here if the toolbar constructor removes <statusbar id="status-bar"/> before add-ons' XUL overlays are loaded.

Comment 13

[Matthew Turnbull [Bluefang]]

Is there a way to allow a toolbaritem to be moved within a toolbar (or between toolbars) without allowing it to be moved back into the palette? There's the removable attribute, but AFAIK that would prevent any customization at all.


Also, in earlier versions of Status-4-Evar, I was using DOM to move the statusbar element to be the last on the addon-bar. However, re-parenting the statusbar element seemed to break the popup-menus that some icons had. I'm not sure if it was breaking the menu its self, or the mouse listeners registered on the icon... but this is something that needs to be watched for to see if it is actually a problem.

Comment 14

[Dietrich Ayala (:dietrich)]

(In reply to comment #12)
> Comment on attachment 487389 [details] [diff] [review]
> wip
> 
> As discussed some time ago in the newsgroups, this would break add-ons putting
> items here, as their formerly permanent items would be able to disappear from
> the document.
> 
> You might also get a race condition here if the toolbar constructor removes
> <statusbar id="status-bar"/> before add-ons' XUL overlays are loaded.

Yep, forgot that it's no longer in the document when removed to the palette.

In that case, it sounds like it's not really feasible.

We should instead implement bug 616016, until we determine if the shim should be removed. -> WONTFIX.

Comment 15

[Dão Gottwald [:dao]]

(In reply to comment #13)
> Also, in earlier versions of Status-4-Evar, I was using DOM to move the
> statusbar element to be the last on the addon-bar. However, re-parenting the
> statusbar element seemed to break the popup-menus that some icons had. I'm not
> sure if it was breaking the menu its self, or the mouse listeners registered on
> the icon... but this is something that needs to be watched for to see if it is
> actually a problem.

I suspect this was due to XBL reconstruction, which would indeed have affected this patch too.

Comment 16

[flying sheep]

@comment 2:
the newest firebug build has now a toolbar button, which works like the old statusbar button.

finally i added “statusbar {display:none}”. now it just has to be removed for good via bug 598929.