Closed Bug 598929 Opened 14 years ago Closed 10 years ago

Remove empty <statusbar id="status-bar"/> from Addon bar

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: tech4pwd, Unassigned)

References

Details

(Whiteboard: [addon bar])

Attachments

(1 file)

Addon Bar Inconsistency
5.36 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b7pre) Gecko/20100923 Firefox/4.0b7pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b7pre) Gecko/20100923 Firefox/4.0b7pre

Granted there's a desire to make the transition from 3.x to 4.x as easy as possible, but you won't get a better time to remove it than for a major release such as 4.0.

Reproducible: Always
Blocks: 574688
Version: unspecified → Trunk
If we remove this, the old addons wont show up. Am I correct? 

The addon devs have to update their addons anyway, and then they update to new addons bar, too. So it encourages to use the addons bar, wich is a good idea.
(In reply to comment #1)
> If we remove this, the old addons wont show up. Am I correct? 
Correct.

> The addon devs have to update their addons anyway, and then they update to new
> addons bar, too. So it encourages to use the addons bar, wich is a good idea.
Exactly. There's been a concern regarding how many addons will be made invalid by such a move, but that won't change in the future so we should press ahead with it now.
It's intentionally there.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Dão, did you think of what we were talking about with Paul?

(I know, you guys did, but please describe why it's intended)
(In reply to comment #3)
> It's intentionally there.

I know it's intentionally there, I followed the comments in the original bug. However I disagree with it being there, hence filing a bug for a review of that decision.
Removing it would break hundreds of add-ons and the migration to the add-on bar wouldn't be trivial in many cases. At the same time, keeping it doesn't really hurt.
It wouldn't be the first major breakage of Firefox 4 for addons. And if we're going to leave it in, then what's the ETA for it's removal? Things have broken continually up till now and they should continue to break so as that Firefox 4 can be the best product possible. Leaving in primitive functionality serves no purpose. You yourself have said in a previous bug that addons should be forced to adapt to Firefox 4, not Firefox 4 adapting for addons. Why is it a different case now?
(In reply to comment #7)
> It wouldn't be the first major breakage of Firefox 4 for addons.

This absolutely doesn't justify increasing the burden for add-on authors even more. Many add-ons also aren't affected by the changes so far and will continue to work with a version number bump. Breaking compatibility always needs a very good reason, even more so if it would affect loads of add-ons.

> And if we're
> going to leave it in, then what's the ETA for it's removal?

We don't need an ETA for the removal. Keeping the element around doesn't hurt.
(In reply to comment #8)
> (In reply to comment #7)
> > It wouldn't be the first major breakage of Firefox 4 for addons.
> 
> This absolutely doesn't justify increasing the burden for add-on authors even
> more. Many add-ons also aren't affected by the changes so far and will continue
> to work with a version number bump. Breaking compatibility always needs a very
> good reason, even more so if it would affect loads of add-ons.
As said, compatibility has been broken a few times during the road to Firefox 4, why not again now? Addon builders will see more than enough time to make the required changes. One of my favourite Addons doesn't work with Firefox 4.0, I'm not petitioning that changes should be reversed or that implemented to get it working again.

> > And if we're
> > going to leave it in, then what's the ETA for it's removal?
> 
> We don't need an ETA for the removal. Keeping the element around doesn't hurt.
There most certainly needs to be an ETA for it to be removed as the Status Bar no longer exists.

Can we add Dietrich (Assignee), Beltzner (PM) and Faaborg (UX Lead) to this discussion?
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > It wouldn't be the first major breakage of Firefox 4 for addons.
> > 
> > This absolutely doesn't justify increasing the burden for add-on authors even
> > more. Many add-ons also aren't affected by the changes so far and will continue
> > to work with a version number bump. Breaking compatibility always needs a very
> > good reason, even more so if it would affect loads of add-ons.
>
> As said, compatibility has been broken a few times during the road to Firefox
> 4, why not again now? Addon builders will see more than enough time to make the
> required changes. One of my favourite Addons doesn't work with Firefox 4.0, I'm
> not petitioning that changes should be reversed or that implemented to get it
> working again.

"Compatibility has been broken before" is not a useful argument. Did you read what I wrote? We break compatibility when we need to, not for fun.

> > > And if we're
> > > going to leave it in, then what's the ETA for it's removal?
> > 
> > We don't need an ETA for the removal. Keeping the element around doesn't hurt.
> There most certainly needs to be an ETA for it to be removed as the Status Bar
> no longer exists.

It doesn't exist and the empty <statusbar id="status-bar"/> doesn't change that. It's just a dummy element, not actually a status bar.
(In reply to comment #10)
> "Compatibility has been broken before" is not a useful argument. Did you read
> what I wrote? We break compatibility when we need to, not for fun.
Removing the Status Bar wasn't done for fun. Pretending it still exists is simply the easiest way out. It is not an argument for keeping it.

> It doesn't exist and the empty <statusbar id="status-bar"/> doesn't change
> that. It's just a dummy element, not actually a status bar.
Which is why it doesn't need to be there, pseudo elements are pointless. We're currently evolving the space and yet the counter argument that sees this pseudo element stay seem to be like the ones that hindered the internet ala IE6, IE7 and IE8.
(In reply to comment #11)
> (In reply to comment #10)
> > "Compatibility has been broken before" is not a useful argument. Did you read
> > what I wrote? We break compatibility when we need to, not for fun.
> Removing the Status Bar wasn't done for fun. Pretending it still exists is
> simply the easiest way out. It is not an argument for keeping it.

We're talking about two different things: the empty <statusbar id="status-bar"/> and the Status Bar. The Status Bar with all its features is gone. <statusbar id="status-bar"/> is a transparent overlay target whose id happens to be "status-bar".
Attached image Addon Bar Inconsistency — 
Nope, we're talking about the same thing. Because by adding the <statusbar id="status-bar"/> I have some Addons using the new method of interaction (Testpilot, NoScript) and then I have icons and usability that's horribly out of place and inconsistent (QA Companion, Ad Block Plus and Tumblr Post) thanks to this being in. There is no argument for promoting inconsistency.
(In reply to comment #13)
> Created attachment 477949 [details]
> Addon Bar Inconsistency
> 
> Nope, we're talking about the same thing. Because by adding the <statusbar
> id="status-bar"/> I have some Addons using the new method of interaction
> (Testpilot, NoScript) and then I have icons and usability that's horribly out
> of place and inconsistent (QA Companion, Ad Block Plus and Tumblr Post) thanks
> to this being in. There is no argument for promoting inconsistency.

The buttons you dropped there aren't actually supposed to look like that. This is bug 598920.
(In reply to comment #14)
> (In reply to comment #13)
> > Created attachment 477949 [details] [details]
> > Addon Bar Inconsistency
> > 
> > Nope, we're talking about the same thing. Because by adding the <statusbar
> > id="status-bar"/> I have some Addons using the new method of interaction
> > (Testpilot, NoScript) and then I have icons and usability that's horribly out
> > of place and inconsistent (QA Companion, Ad Block Plus and Tumblr Post) thanks
> > to this being in. There is no argument for promoting inconsistency.
> 
> The buttons you dropped there aren't actually supposed to look like that. This
> is bug 598920.

Behavioural inconsistency doesn't vanish as per that bug though.

By the way, could you mark bug 598920 as new please.
dao, the google groups discussion was supposed to be about that. how come you decided quietly that the case is settled and you have “won”?

we did still not hear arguments convincing enough to keep the zombie <statusbar>. until you deliver these we are still convinced that it needs to die.
(In reply to bug 574688 comment #234)
> with regard to the statusbar compatibility shim: as we discussed in the
> newsgroups, there are technical issues with the migration of statusbar addons
> to the add-on bar that need to be addressed before we can fully remove the
> statusbar shim.
Why is the onus on Mozilla for the migration from Status Bar to Addons Bar in this case when it wasn't in other cases that have broken masses of extensions? Especially at the expense of behavioural consistency as mentioned above. While I certainly hope bug 598920 will remove the button styling as it stands. I do hope a more compact styling that allows for things like drop downs will appear in it's place; which this bug supports.
I'd agree with the views expressed here that we should not keep the Status Bar remnants in the Addon bar. Like in one of the comments above, release of Fx 4 is the best opportunity for developers to update their addons...they have to do it anyways, to make it compatible with Fx 4... so changing a few lines of code to adjust to the new Addons bar shouldn't be such a huge issue. 

A lot of new things in Fx 4 have broken addons - XPCOM, XPI packagiing, API changes etc., so this isn't an isolated case, and shouldn't be treated like one.

Fx 4 is a big release - things break... and they will be fixed over time.
As Mike Connor pointed out in regards to concerns that removing the element will break extensions attempting to support both 3.6.x and 4.x: "You can simply register different overlay files for different app versions using chrome registration bits (application and appversion, basically).  http://mxr.mozilla.org/services-central/source/fx-sync/addon/chrome.m... is how we disable Firefox Sync UI pieces in Firefox 4 b4 and higher, and allow the in-product UI to take over.

This would allow you to have one overlay that put the UI into the addon bar in Fx4, and one that used the old UI in 3.6.  Is that sufficient?"

The crux of the argument in the newsgroup for keeping this has evolved no further than 'extension developers reserve the right to be lazy' and they do, but that shouldn't halt the evolution of this browser. It was premature to mark this as invalid, as such I'm going to re-unconfirmed.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
The full link that Mike posted on the newsgroup: http://mxr.mozilla.org/services-central/source/fx-sync/addon/chrome.manifest.in#2
Requesting blocking for final release, there's just not a good argument to keep it. And having a set date for removing it will encourage Addon Developers to update their code.
blocking2.0: --- → ?
Is this being worked on? Currently the addonbar is not optional as intended, since addons can (and do) still use unmoveable overlays.

The moment they can’t do this anymore will be the moment they add a simple version switch which adds the overlay for 3.6 and the new widget/button for 4.0
It's not going to land for b7, breaking addon APIs post-API-freeze is a no-no, particularly not breakage for breakage sake. This is a compat shim that one can like or not like, but if we're gonna kill it, we're gonna do it post-4.0.
blocking2.0: ? → -
not cool.
the discussion was supposed to happen here: http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/9f91bd1618339b6a/
…but there weren’t really any arguments for keeping the hack. somebody thought “**** it”, though, and didn’t care, which resulted in it not being included in the api change.

there should either be made an exception here, since encouraging new addon creators to ignore the new way by keeping the old one working is a no-no, too.

or (the only other possibility): include the removal in the next possible release (read: the next release which is not solely and totally for bugfixing) and include big, bold warnings in *every* addon development pipeline:
on mdc, addons.mozilla.org, and in every single sdk, toolkit and blogpost which is remotedly related to “adding stuff to the ui”.
To be fair, the way the shim made it into trunk was a bit underhanded looking from the outside in.
I'm lost as to what the new method for adding a button to the add-on bar which is movable/customizable like it's supposed to be, except to use the add-on sdk which isn't much of a option for a add-on planning to support FF < 4, and it's probably possible to figure out how to do this by reviewing that source, but shouldn't there at least be very good documentation provided on the new way/method before the old way is removed? if I just haven't seen it then can someone please point me to it?
Whiteboard: [addon bar]
Can we get an ETA for removal of status bar shim?
The documentation is here: https://developer.mozilla.org/en/The_add-on_bar
But it's not ready yet.
could you please tell us if this is still the case, and if so, what is missing?
Any chance we can set a target milestone for Firefox 8 on this? That would've given Add-On developers enough time to prep for the removal of this?
We should not set a milestone on this until we've got data about it's use by add-ons. Perhaps we could get data from the AMO team about how many add-ons are compatible with 4.0 and use the shim.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → RESOLVED
Closed: 14 years ago → 10 years ago
Resolution: --- → INVALID
No longer depends on: 956731
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: