Closed Bug 278889 Opened 20 years ago Closed 20 years ago

TBE broken

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: mmoy, Assigned: bugzilla)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050112 Firefox/1.0+ (Firefox CE Trunk 2004-12-23 P4W-X15)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050118 Firefox/1.0+

Something checked in before 11:00 PM EST on January 17, 2005 has broken TBE. TBE
doesn't work at all now. I suspect some of the Javascript changes but that's
just a wild guess. Moox' build early morning 1/17 doesn't show the problem. I did a
build on a pull late 1/17 and it has the problem. The problem shows up in the
Official 1/18 nightly.

Reproducible: Always

Steps to Reproduce:
1. Install TBE or use a profile that already has it
2.Try to use any TBE features like sidebar in left hand side.
3.

Actual Results:  
TBE doesn't do anything that TBE usually does.
That's a TBE problem, not a FF problem.  Report it to the TBE author.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Well, I suppose I could do that but I don't think that Piro can debug Firefox or
Mozilla. TBE has been working for quite some time and I suspect that one of the
code checkins yesterday broke it. It probably broke other stuff too unless this
was an intentional break of some behaviour in Firefox that I'm not aware of.

At any rate, this is a pretty poor attitude for a product. At least that's the
point of view of someone that worked as a support engineer for five years.

It appears that it will be pretty straightforward identifying the offending code
and maybe I'll be able to find something else that's broken. I did find some
Javascript anomalies on this trunk and maybe they're related.

Is this the official line on TBE issues or are triaging resources really that bad?
I'd like to add that Click2Tab has an option to clear session history when the
last tab is closed. That no longer functions.  Worked fine in yesterday's build.
It's not the official line on TBE, it's the official line on extensions, and the
bargain that all of us as extension authors sign on for: since our code doesn't
have to get reviewed, and isn't even known to Moz developers, they get to break
us with impunity. An extension author can certainly file a bug if a code change
leaves Moz broken in a way that his code exposes, but if it's just a matter of
changes that he needs to change to meet, then it's all up to him. If a developer
is checking in something that breaks code in another part of Moz itself, then he
needs to fix that code, and can fix that code, but expecting devs to check every
change against every single extension, even though they have no way of changing
them, would just mean that nothing would ever be done.
(In reply to comment #4)

If I, as an engineer, break someone elses code, I'd want to know about it as
soon as possible as corporate costs from bugs grow exponentially outward from 
engineering to end-users.

It's true that an extension can rely on the behaviour of a bug but it seems
pretty easy to triage this particular problem given the narrow window of checkins
regarding this problem. If it was intentional, that's easy to determine once the
code culprit is found. This is very common in large engineering shops where you
have thousands of engineers working on a product. If you break something big,
then a lot of other engineers will look at it wasting 15 to 30 minutes of a
thousand of more people. It's a lot more efficient if the first person shouts
out the problem so that it can migrate back to the responsible engineer.

Perhaps triaging resources are really that bad as I have a reproduceable crash
case which has been confirmed by others that hasn't been looked at by a
developer yet.

The least this guy Mason could do is to leave it open or assign it to me as I'm
working on finding the culprit code change. That way, at least other extension
developers would have a clue as to what broke them if it's the fault of the
extension developer. If it's a code problem, then that would be discovered too.

As a former corporate support engineer, one thing that's common is that
customers absolutely hate finger pointing. But it's something that is apparently
lost on a lot of folks triaging products.
Looks like the big command-line checking has broken a few extensions and a few
other things. But I'll do a few other things to make sure that this is the problem.
I found the code checkin that caused the problems. I don't really think anyone
cares so I'll just do my own builds without the code.
If a checkin caused the breakage, and the fix is _wrong_ then let us know by
filing a bug on the patch author/reviewer and explaining why the API change is
faulty.  

If the fix is _right_ then extension authors have to fix their callers to work
again.  The only thing that should be done is a low-volume list for extension
authors so that if something like this happens, the information can be
distributed.  That isn't really something within the Bugzilla context, as our
code isn't broken, per se.

For the record, TBE has been breaking at regular intervals since at least June
2003, when I stopped using it.
Status: RESOLVED → VERIFIED
At this point, I don't really care. I'll just use the source code before the
checkin.
It turns out that it broke some other stuff. Something about DDE startup has
been discussed in some MozillaZine thread. So maybe someone else will enter a
Bugzilla for it.
Also, for the record, http://piro.sakura.ne.jp/xul/tabextensions/tradeoff.html.en

I'm actually quite shocked that TBE from August seems to work fine, per your
comments in the MozillaZine thread.  The entire reason the extension manager was
put into place was to allow for the simple fact that APIs will change between
versions, and external code needs to be tested/updated before certification with
a new version.

I'm still not sure what you really wanted out of this bug.

1) Someone to track down why it broke and fix it.
2) Someone to track down why it broke and provide an advisory.

Either are basically up to Piro, by his own admission: "Virtually, now no one
can update TBE codes, excluding me. Its codes are like as entwined spaghetti.
Many unknown bugs are maybe there, many known problems (with unknown reasons) too."
> I'm actually quite shocked that TBE from August seems to work fine, per your
> comments in the MozillaZine thread.  The entire reason the extension manager was
> put into place was to allow for the simple fact that APIs will change between
> versions, and external code needs to be tested/updated before certification with
> a new version.

I had to do a minor hack to it but it's what I use when setting up others with
a Firefox installation. Using an old version that is stable keeps everything
running smoothly.

> I'm still not sure what you really wanted out of this bug.

Someone to look at the code change that caused the difference in behaviour and
to fix it if it was a code problem. I read that there were code changes being
made to the code change that caused this problem so that the developer is
apparently aware of problems with his checkin. It seems to have broken a few
other things too with many uses reporting on the other problem.

> Either are basically up to Piro, by his own admission: "Virtually, now no one
> can update TBE codes, excluding me. Its codes are like as entwined spaghetti.
> Many unknown bugs are maybe there, many known problems (with unknown reasons) 
> too."

You assume the problem is in his code.

I've looked at the code but decided that I'd rather do performance stuff instead
of rewriting TBE. TBE was a lot simpler in the old days and it may be easier to
just start with a much older version and then move forward. Or have Piro
document TBE in a way that others could work on it.

For me and many others, TBE works just fine and we don't understand the
developer animosity towards it. Yes it does some stuff that's hackish but
I imagine there's lots of code in Mozilla that does similar things.

I do recall that there was code hanging around in the nightlies that could
wipe out your program files directory and that it was active for about a
month.
is this actually the command-line handling rewrite we're talking about or
something else?  If it is, that's a lot of code to re-review on the basis that
there might be a problem.  Knowing what type of code actually fails makes a huge
difference.

Either his code is simply buggy, or his code is passing something that we're
choking on.  Regardless, knowing WHAT is failing is much easier than a
theoretical trip through a major patch, looking for potential issues.  If you
can say "If X does A then B, it fails at C" its immensely more useful than "X
isn't working since this patch landed."

Where your argument breaks down is on the presumption that we're somehow
responsible for making external extensions work if we break them.  If we break
them, the onus has always been on the author to investigate why and provide a
fix or file a bug with the details of why something fails and shouldn't.  This
is the traditional and accepted development process for unofficial
themes/extensions.  Sorry if it doesn't meet your standards, but we do things
this way for a reason.

(In reply to comment #12)
> I do recall that there was code hanging around in the nightlies that could
> wipe out your program files directory and that it was active for about a
> month.

This isn't relevant, and some people will look at this as trolling.
> is this actually the command-line handling rewrite we're talking about or
> something else?  If it is, that's a lot of code to re-review on the basis that
> there might be a problem.  Knowing what type of code actually fails makes a huge
> difference.

> Either his code is simply buggy, or his code is passing something that we're
> choking on.

Well, I think your logic is flawed here. Boolean simplicity I think.

> Regardless, knowing WHAT is failing is much easier than a
> theoretical trip through a major patch, looking for potential issues.  If you
> can say "If X does A then B, it fails at C" its immensely more useful than "X
> isn't working since this patch landed."

I can't say as I haven't looked at either. I simply reported a problem that in
my opinion is a code problem.

> If you can say "If X does A then B, it fails at C" its immensely more useful 
> than "X isn't working since this patch landed."

I was trying to point out a problem. You're looking for something more useful
to yourself, or, perhaps someone else. There's a vast gap there that's common
to users and engineers. Support should be there to bridge that gap. But it
appears that support is lacking here.

> Where your argument breaks down is on the presumption that we're somehow
> responsible for making external extensions work if we break them.

As a professional engineer, I want to know when I break someone elses code
unless it was planned and announced or deprecated. I would think that other
engineers would feel the same way. Perhaps I'm wrong in this assumption of
professional engineering practices.

Think of the cost in time of breaking a bunch of extensions vs announcing
changes so that extension writers and users don't get blindsided. In general
engineering terms, costs grow exponentially outward from engineering.

> If we break them, the onus has always been on the author to investigate why 
> and provide a fix or file a bug with the details of why something fails and 
> shouldn't.  This is the traditional and accepted development process for 
> unofficial themes/extensions.  Sorry if it doesn't meet your standards, but we
> do things this way for a reason.

Yeah but everyone hates cost shifting when the cost is shifted to us. Not
exactly user-friendly either. And no fun at all when you're arguing with Opera
users about Firefox' extension hell. I can certainly see their point though
I don't like to admit it in public.

> This isn't relevant, and some people will look at this as trolling.

Some people could look at people filing bugs as trolling.

I had several requests to do builds on recent trunks but have avoided the
trunk for quite some time exactly because of these kinds of problems preferring
to let other people deal with bugs and breakages. But I gave the trunk a try
and I get a load of crap for the effort.

It would seem that not filing bugs would require much less of an expenditure
of energy on my part in the future.
If extension authors don't want to deal with API changes, then they should rely
only on frozen interfaces.  If they need to use an unfrozen inteface, they can
access it by classID, ensuring that if the API changes then they'll be able to
get feedback/debugging info, instead of broken behaviour.  Unfrozen interfaces
are "use at your own risk" for external code, and subject to changes, big or
small, without external notification.  And if we said something like
"nsIPermissionManager has changed remove() to take an nsIURI, not a host string"
I don't even believe that would be enough to avoid problems.

Using unfrozen interfaces without a safety net is the choice of the extension
author.  If they choose to write code that isn't future-proof, the onus is on
them to keep it updated.  If extension authors aren't willing to play by those
rules, they should state that they're only going to support version X.

The cost shifting you're talking about should never end up on the user.  If
there is a bug, report it to the extension author.  They are the first stage in
the support chain for extensions, as they should be.  The cost of maintaining
extensions built against unstable APIs is continued debugging and bugfixing to
keep pace.  That's not just a Firefox issue, its an issue everywhere in the
software world.
You need to log in before you can comment on or make changes to this bug.