138496 - Back out linktoolbar (site nav bar) from 1.0 branch :(

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Stuart Ballard]

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.

Comment 1

[Kai Lahmann (is there, where MNG is)]

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.

Comment 2

[Stuart Ballard]

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.

Comment 3

[Andrew Hagen]

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

Comment 4

[Andrew Hagen]

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.

Comment 5

[Chris Hubick]

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.

Comment 6

[Stuart Ballard]

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?

Comment 7

[Mike Utke]

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.

Comment 8

[Stuart Ballard]

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.

Comment 9

[Asa Dotzler [:asa]]

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. 

Comment 10

[Stuart Ballard]

Attachment: Remove the linktoolbar

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

Comment 11

[Stuart Ballard]

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

Comment 12

[Boris Zbarsky [:bzbarsky]]

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

r=bzbarsky.... <sigh>

Comment 13

[Stuart Ballard]

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

Comment 14

[Boris Zbarsky [:bzbarsky]]

Yeah, one of them or jag.

Comment 15

[jag (Peter Annema)]

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

sr=jag

Comment 16

[Asa Dotzler [:asa]]

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

a=asa (on behalf of drivers) for checkin to the 1.0 branch

Comment 17

[Boris Zbarsky [:bzbarsky]]

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....

Comment 18

[Scott Davis]

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

Comment 19

[Boris Zbarsky [:bzbarsky]]

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....

Comment 20

[Stuart Ballard]

Attachment: Untested xpi

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.

Comment 21

[Ben Bucksch (:BenB)]

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.

Comment 22

[Greg Valure]

Should this have a release note?

Comment 23

[Stuart Ballard]

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.

Comment 24

[Matthias Versen [:Matti]]

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