Per discussion with drivers, it seems that they want the linktoolbar (site navigation bar) backed out for 1.0 due to the absence of a fix for bug 102992 (perf issues). This is a bug to do that. I've assigned it to myself because I don't know who else to assign it to, but I probably won't have time to do it, so I'm leaving it as NEW. If this does get approved for 1.0 (which I expect it to), someone else will have to take it and produce the (trivial) patch to remove the overlay from navigator.xul. Other possibilities: Make the linktoolbar an XPI that can be installed after the fact, or even make it an XPI that can be optionally installed as part of a mozilla installation (ie a separate component). I should add that I don't *want* this to happen, but I'm filing this bug anyway because I know that drivers *do* want it to happen, and I wouldn't want it to stay in just because drivers are so busy that they forgot. If you have a problem with this, don't complain to me or to drivers, either fix bug 102992 or come up with the changes to make this an optional XPI.

noooooooo! the bar is the most important thing to say "mozilla fully supports HTML" ! don't do it, or the MSIE fans won't stop laughing for weeks.

Kai, please read the last sentence of the initial description of this bug... "If you have a problem with this, don't complain to me or to drivers, either fix bug 102992 or come up with the changes to make this an optional XPI." Particularly the latter course of action shouldn't be too hard! Anyone who has written code for mozdev knows how to create an XPI. Some of the initial patches in bug 2800 and bug 87428 were in the form of XPIs that used a dynamic overlay to put this into navigator.xul, and none of the changes since would prevent switching back to that mode of operation for 1.0. I honestly don't think drivers would care if you submitted a patch that added a checkbox to the installer for the site navigation bar, and created a linktoolbar.xpi as part of the build process - I think such a patch would be accepted. And you could even turn the linktoolbar on by default! And apply the patch in bug 103428 (with some tweaks like making sure that the linktoolbar is installed before trying to operate on it) to make it work with tabs! By all means, work on creating something like that! Or something else that would actually *solve* the problem. But drivers have determined that a 3% startup and new-window time slowdown is unacceptable, and you can't blame them for that, considering that startup and new-window time are among the most frequent complaints about mozilla. Unless you have an actual solution, complaining about this (much as I sympathize - I love the toolbar too!) isn't helping anything.

Wish you would have said something earlier. I wasn't aware of this problem with the links toolbar until today.

Just for the record, the small, one-time performance loss is minor, compared to the large potentiall loss of functionality if we back out. We shouldn't back out. We shouldn't have to rewrite the entire links toolbar for 1.0. Just release 1.0 with the current links toolbar implementation, and then rewrite it for the 1.0.1 release.

I agree with Andrew. Removing highly useful and visible features, which in turn causes lower HTML conformance, in order to achieve a slight performance win, is an over- optimization.

It's not "highly visible" since it's not even turned on by default. It also doesn't work right with tabs, which are another "highly visible" feature. I appreciate the verbal support for the feature, guys, but really, if you want to support the linktoolbar the only way that will make a difference at this late stage is to provide some code. Honestly. I really do believe that someone with HTML experience, a day or two to hack in, and the ability to investigate and experiment and figure things out, would probably be able to make an XPI in time for 1.0. With so much verbal support, why is there such a conspicuous absence of support by actions?

Why won't someone act and make an XPI? Because making an XPI to break the toolbar out of 1.0 would doom the linktoolbar. Those who feel this is essential for full HTML support are not the most likely candidates for removing the feature from the 1.0 release. Because this is still a NEW bug, the odds of getting the linktoolbar yanked seem to go down with every passing day. Yes, supporters should be working on bug 102992, but nobody is claiming that the drivers will choose between resolving this bug or 102992. Just trying to answer an honest question with an honest response. If you want to see activity, find a way to make the threat to linktoolbar real.

The threat is extremely real. This bug is a dependency on bug 138000, which indicates bugs that drivers have decided MUST be fixed for 1.0RC2. Bug 102992 is not a dependency on bug 138000. I forget whether it was in bug 102992 or in private email, but one of the drivers said to me that if 102992 could be fixed with a "simple patch", it might be accepted for 1.0, but if it needed a "major rewrite" it would not. The only proposed solution to bug 102992 right now (and what the partial non-working patches implement) is a major rewrite. Therefore bug 102992 would probably not be accepted even if somebody *could* get the patch finished in time. Lastly, I don't see where you see "current activity" on bug 102992. I follow that bug pretty darn closely, and the only people who've recently suggested they might actually work on the patch don't seem to have had any success - and haven't posted any recent progress reports either. The bug seems currently dead to me. Note that an XPI doesn't necessarily mean the feature is doomed. If the XPI could be made a checkbox in the "custom installation" of mozilla, then the XPI could have it turned *on* by default and might, therefore, make it *more* visible than it is today, where people only see it at all if they delve in the view menu. I expect quite a few people use the custom installation, compared to those who delve through all the menus when they run it for the first time.

So who is making the patch? We're wrapping up RC2 and the performance issues have not been resolved. That makes this a 1.1 or later feature and it needs to be pulled from the MOZILLA_1_0_0_BRANCH.

This patch removes the overlay for the linktoolbar. That will resolve the perf issues. Optionally, the linktoolbar's files could be removed as well, but I'm not sure that's worth it. Doing things this way would make it easy to re-add the linktoolbar by adding the existing overlay to the dynamic overlays file, I think (although I don't know a whole lot about how dynamic overlays work, so I could be wrong).

bz, care to return the favor and review this one? :)

Comment on attachment 81669 [details] [diff] [review] Remove the linktoolbar r=bzbarsky.... <sigh>

Who's a good person to ask for sr= from for this kind of patch? Blake or Ben maybe?

Yeah, one of them or jag.

Comment on attachment 81669 [details] [diff] [review] Remove the linktoolbar sr=jag

Comment on attachment 81669 [details] [diff] [review] Remove the linktoolbar a=asa (on behalf of drivers) for checkin to the 1.0 branch

Checked in on the 1.0 branch (but _not_ trunk). Let's focus on getting this thing into good enough shape on the trunk that it can go on in 1.1 or so....

For people who WANT to use the link toolbar, even in 1.0, what will be the minimalist way of restoring it?

Well, the silly way is to unzip comm.jar, add the line the patch took out to navigator.xul, and rezip comm.jar. I suspect it would be possible to do an XPI that does all that, but I've never done XPI stuff before, so I'm not a good source of info on that....

Here's a bastardized XPI made from the original linktoolbar.xpi from days of yore. I took out all the content, skin etc and left only the contents.rdf, which I changed to point to the existing overlay file that already lives in chrome. It's untested because I don't have a 1.0pre build around right now. Use at your own risk, and please, if it doesn't work, look at the contents and try to figure out what's going wrong. Note that due to a bugzilla issue, you will probably need to save this to disk with an xpi extension and then load it into mozilla using a file:/// url; otherwise mozilla won't believe it's really an xpi. Someone with more knowledge than me will have to investigate what it would take to make this part of the build process and ship the xpi as an optional part of the installation. If you are thinking of doing that, please make sure that the hidden="true" in linkToolbarOverlay.xul gets changed to hidden="maybe" as part of the same patch, otherwise even if someone installs it, it will be disabled, which will be confusing to the user.

While I strongly disagree with this bug, I am glad that you removed one line only. This allowed me to readd the link toolbar for Beonex Communicator 0.8-pre despite an emergency, and will allow others to readd it with a bit chrome/jar-file hacking.

Should this have a release note?

Ben, if you are shipping the linktoolbar in Beonex, could I please request that you apply the patch in bug 103428? It fixes the linktoolbar breakage with tabs along with adding a little bit of logic to avoid the toolbar popping in and out of existence as you switch tabs. I haven't tested it in a while but at the time it worked... Are you planning on turning the linktoolbar on by default in Beonex? That's a one-liner also, and I can provide a patch if you want. I know of no performance penalty or other problem from doing so, except for the tab issue which 103428 fixes. Greg, I personally wouldn't suggest relnoting this. 1.0 is Mozilla's *first* "official" release, and only people who have used previous incarnations of Mozilla will care about its absence. I think that most people who have used Mozilla up to now and were able to find the linktoolbar in the first place will be able to find other sources of information as to why the feature went away.

*** Bug 143727 has been marked as a duplicate of this bug. ***