Closed
Bug 138496
Opened 23 years ago
Closed 23 years ago
Back out linktoolbar (site nav bar) from 1.0 branch :(
Categories
(SeaMonkey :: UI Design, defect)
SeaMonkey
UI Design
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: sballard, Assigned: sballard)
References
Details
Attachments
(2 files)
622 bytes,
patch
|
bzbarsky
:
review+
jag+mozilla
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
1.41 KB,
application/x-xpinstall
|
Details |
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•23 years ago
|
||
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.
Assignee | ||
Comment 2•23 years ago
|
||
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•23 years ago
|
||
Wish you would have said something earlier. I wasn't aware of this problem with
the links toolbar until today.
Comment 4•23 years ago
|
||
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•23 years ago
|
||
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.
Assignee | ||
Comment 6•23 years ago
|
||
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.
Assignee | ||
Comment 8•23 years ago
|
||
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•23 years ago
|
||
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.
Assignee | ||
Comment 10•23 years ago
|
||
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).
Assignee | ||
Comment 11•23 years ago
|
||
bz, care to return the favor and review this one? :)
Comment 12•23 years ago
|
||
Comment on attachment 81669 [details] [diff] [review]
Remove the linktoolbar
r=bzbarsky.... <sigh>
Attachment #81669 -
Flags: review+
Assignee | ||
Comment 13•23 years ago
|
||
Who's a good person to ask for sr= from for this kind of patch? Blake or Ben
maybe?
Comment 14•23 years ago
|
||
Yeah, one of them or jag.
Comment 15•23 years ago
|
||
Comment on attachment 81669 [details] [diff] [review]
Remove the linktoolbar
sr=jag
Attachment #81669 -
Flags: superreview+
Comment 16•23 years ago
|
||
Comment on attachment 81669 [details] [diff] [review]
Remove the linktoolbar
a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #81669 -
Flags: approval+
Comment 17•23 years ago
|
||
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•23 years ago
|
||
For people who WANT to use the link toolbar, even in 1.0, what will be the
minimalist way of restoring it?
Comment 19•23 years ago
|
||
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....
Assignee | ||
Comment 20•23 years ago
|
||
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.
Updated•23 years ago
|
Attachment #81858 -
Attachment mime type: application/octet-stream → application/x-xpinstall
Comment 21•23 years ago
|
||
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•23 years ago
|
||
Should this have a release note?
Assignee | ||
Comment 23•23 years ago
|
||
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•23 years ago
|
||
*** Bug 143727 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•