too many OS menu options, bug 167002
jos...@gmail.com
was broken up into multiple OS options (10.0, 10.1, 10.2...). I think
this should be reversed, the OS menu should go back to having a single
Mac OS X option. For many of us who deal with Mac OS X bugs all day
most days it is frustrating to have so many options. There are many
things we could theoretically change about how bugzilla works in this
respect to make the whole system better, but for now a I think we need
to do the simple thing - go back to a single Mac OS X option.
Reasons not to have so many options...
1. The expanded OS field is useless for developers because even though
most bugs affect all OS versions, the field must be set to one
particular OS version. This means that for the 99% of bugs that affect
all versions, their fields are set to some random OS version. When I
see a bug marked as 10.3, I can't assume that it means anything
whatsoever, and if I cared, I would still ask in the bug no matter what
that field said.
2. Every time a new OS is added (which happens much more frequently on
Mac OS X than it does Windows), you have to regenerate any saved
queries.
3. Every time I search I have to select a bunch of options instead of
just one.
4. In general, the extra OS version are just noise that makes it easier
to miss things in queries.
5. Having the menu set up this way generates more bugmail for everyone
when people fiddle around moving bugs between OS version. Since most of
the developers who fix Mac OS X bugs regularly don't use this field for
anything, it unnecessary noise. I want to be notified when a bug goes
from Windows to Mac OS X, but not when Mac OS X 10.3 goes to 10.4
because the latter means nothing.
Some arguments for leaving the menu as is boil down to, "if we can
collect that information, why not do it?" The problem is that the
information is so unreliably collected in the OS field that all of it
is utterly useless. If a bug affects 10.3 *only*, then put [10.3] at
the beginning of the summary, and that is a much more effective way to
communicate that information. That happens for very few bugs, so it is
an appropriate use of the summary field imo.
Another argument for leaving the OS menu as is comes down to "but
Windows does it too!" For one thing, I feel the same way about Windows.
Having multiple options for Windows at this point is frustrating in
many of the same ways that it is for Mac OS X. Secondly, this being
done for Windows does not mean we have to do it for Mac OS X - we can
make this decision based on a discussion of the merits instead of
precedent.
Most Mac OS X developers I know of are against this change, and they
should have been consulted before it was made. Hopefully we can have a
good discussion about reversing this here, in a place where everyone
can participate.
Eric Shepherd
It's easy enough to say in the bug summary that a specific version of
the OS is affected.
Eric Shepherd
Developer Documentation Lead
she...@mozilla.com
stuart...@gmail.com
Mac core bugs, and I have never once found that field useful. All it
does is, as Josh said, make a moving target for all queries, making it
worse than nothing from my perspective.
Just as an added point:
6. Even if we could magically trust that field to have correct
information, it's not sufficient to encode information about what a bug
affects: it's not uncommon for something to be broken before or after a
given version, meaning that there would have to be selections for every
possible OS range as well, which isn't practical.
I'm strongly in favor of having a single OS X option.
jos...@gmail.com
google groups discussion to represent him:
=======================================
Our lead bug triager on Camino (Smokey) came out in opposition of
this bug (comment 13).
For the 0.1% of bugs that are OS-version specific, it's much better
for everyone involved to just add something to the subject line than
hope someone notices a combobox buried among the 20 other fields
nobody uses.
I'm with Josh on this: listen to our Mac dev/qa community. None of
them want it.
=======================================
L. David Baron
Do you know who made the change, and why? Have you asked them to
undo it?
Emailing dev-planning to suggest it be reverted might not succeed,
since the right person may not be listening. I'm not sure who owns
that type of bugzilla administration right now, although I suspect
it might be mconnor, and if not, I think he would know.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
Mike Connor
On 13-Dec-06, at 2:38 PM, L. David Baron wrote:
> On Wednesday 2006-12-13 10:38 -0800, jos...@gmail.com wrote:
> Do you know who made the change, and why? Have you asked them to
> undo it?
>
> Emailing dev-planning to suggest it be reverted might not succeed,
> since the right person may not be listening. I'm not sure who owns
> that type of bugzilla administration right now, although I suspect
> it might be mconnor, and if not, I think he would know.
>
> -David
I'm not the b.m.o admin, that'd be justdave more than anyone. Josh
was asked to post here to get more perspective, coming out of private
mail into the wider community.
For what its worth, we could consolidate Windows into Windows 9x /
Windows 2000/XP/2003 Server / Windows Vista for much of the same
rationale. IMO we should make this decision based on overall
principles, not just on what the Mac guys want.
That said, having the different versions isn't especially useful. I
don't know how much this matters, but we should really collate the
old MacOS entries as well, since they're all dead now...
-- Mike
Myk Melez
> I'm not the b.m.o admin, that'd be justdave more than anyone.
justdave is the admin, but I don't think he's the policy person, and
this is a policy question more than an admin question. Asa and timeless
used to handle component requests (maybe they still do), but I'm not
sure we ever had a clear "module owner" for issues like this one.
> For what its worth, we could consolidate Windows into Windows 9x /
> Windows 2000/XP/2003 Server / Windows Vista for much of the same
> rationale. IMO we should make this decision based on overall
> principles, not just on what the Mac guys want.
The other option is to add "Windows" and "Mac OS X" items to the menu
without removing the version-specific items, so reporters can file most
bugs into the general category while still retaining the option to
categorize the truly version-specific ones.
But that's probably more trouble than it's worth, and it's better to
just replace the version-specific items with a single generic one.
-myk
stuart...@gmail.com
> The other option is to add "Windows" and "Mac OS X" items to the menu
> without removing the version-specific items, so reporters can file most
> bugs into the general category while still retaining the option to
> categorize the truly version-specific ones.
For the reason I mentioned above, the individual versions are not
sufficient for that task, so they wouldn't be useful even if we could
trust everyone filing bugs not to pick their specific version from the
list instead of leaving it generic (which we couldn't).
Matthew Willis
> The other option is to add "Windows" and "Mac OS X" items to the menu
> without removing the version-specific items, so reporters can file most
> bugs into the general category while still retaining the option to
> categorize the truly version-specific ones.
between a bug that affects all Mac OS X versions and one that affects
only "10.3.9 with Security Update 2006-03 on PPC hardware..." You get
the idea.
More choices, at least in this case, seem bad. mkay?
> But that's probably more trouble than it's worth, and it's better to
> just replace the version-specific items with a single generic one.
To quote dmose, word.
-lilmatt
jos...@gmail.com
> The other option is to add "Windows" and "Mac OS X" items to the menu
> without removing the version-specific items, so reporters can file most
> bugs into the general category while still retaining the option to
> categorize the truly version-specific ones.
>
> But that's probably more trouble than it's worth, and it's better to
> just replace the version-specific items with a single generic one.
In addition to the general complexity, that option also leaves saved
queries as a moving target, which is frustrating.
Gavin Sharp
> Myk Melez wrote:
>> The other option is to add "Windows" and "Mac OS X" items to the menu
>> without removing the version-specific items, so reporters can file
>> most bugs into the general category while still retaining the option
>> to categorize the truly version-specific ones.
> History tells us that Jane Q. Bugreporter won't know the difference
> between a bug that affects all Mac OS X versions and one that affects
> only "10.3.9 with Security Update 2006-03 on PPC hardware..." You get
> the idea.
That argument would be valid if Bugzilla was designed solely for Jane Q.
Bugreporter, but it isn't. It's designed for people who want to keep
track of a multitude of different bugs. Bugzilla's end-user unfriendless
is an entirely different problem that should not muddy this discussion
about a specific field and it's values. :)
Gavin Sharp
> 6. Even if we could magically trust that field to have correct
> information, it's not sufficient to encode information about what a bug
> affects: it's not uncommon for something to be broken before or after a
> given version, meaning that there would have to be selections for every
> possible OS range as well, which isn't practical.
It sounds like you're saying "lets not make it better because it still
wouldn't be perfect". The vast majority of bugs are either not OS
specific, OS specific, or minor version OS specific. The small minority
of bugs that are "minor version specific across different minor version
ranges" wouldn't be any worse off if we had an accurate way to specify
the other three states. The next-broadest category could be used for
such bugs.
Gavin
Gavin Sharp
> 5. Having the menu set up this way generates more bugmail for everyone
> when people fiddle around moving bugs between OS version. Since most of
> the developers who fix Mac OS X bugs regularly don't use this field for
> anything, it unnecessary noise. I want to be notified when a bug goes
> from Windows to Mac OS X, but not when Mac OS X 10.3 goes to 10.4
> because the latter means nothing.
>
Being able to better filter bugmail is a separate issue, really, and the
bugmail is only "useless noise" because the field itself is, for the
reason given below.
> Some arguments for leaving the menu as is boil down to, "if we can
> collect that information, why not do it?" The problem is that the
> information is so unreliably collected in the OS field that all of it
> is utterly useless. If a bug affects 10.3 *only*, then put [10.3] at
> the beginning of the summary, and that is a much more effective way to
> communicate that information. That happens for very few bugs, so it is
> an appropriate use of the summary field imo.
>
I think this is your most convincing argument. We should try to make it
easier for the information to be collected when it's available, and make
sure that the default state is easily discernible rather than one of the
other values.
I think the two main issues are as follows:
- some people who fix/triage Mac bugs (e.g. you) would like Bugzilla to
provide an easy way to "find all OS X bugs", and the current dropdown
with multiple Mac options makes this inconvenient
- some other people (me) want to use Bugzilla's OS/Version fields to
limit a bug's scope rather than arbitrary additions to the summary or
other workarounds, so that bugs that are specific to an OS are easily
and consistently findable.
I think that the optimal solution to the problem would be to introduce
an "OS Sub-Version" field that lists minor versions for the selected OS,
like (10.1, 10.4, NT, 2000, XP, etc). This field would default to "All".
That way bugs that are specific to an OS could be easily marked and
found, but broader categories would be available for the majority case
of bugs that affect all or multiple versions of an OS. This solution
would address both issues equally.
That being said, I realize that implementing this suggestion in Bugzilla
(and then getting it to b.m.o) is probably not a trivial undertaking,
and isn't likely to happen soon enough to appease your frustration with
the current situation. Given that the majority of Mac bugs are not
isolated to a specific minor OS version, the best option left to fix
this in a short time frame would probably be to to revert to a single
"Mac" value for b.m.o's OS field, as you suggest. I don't like this
change, because it conflicts with issue #2 above (and for all of the
reasons I listed in my comments to bug 167002), but I guess it's only
viable short-term solution to address your concerns. I suppose it's best
to let your real-world Bugzilla annoyances trump my Bugzilla
all-fields-should-be-set-correctly-all-the-time idealism :)
Gavin
Gervase Markham
> For the reason I mentioned above, the individual versions are not
> sufficient for that task, so they wouldn't be useful even if we could
> trust everyone filing bugs not to pick their specific version from the
> list instead of leaving it generic (which we couldn't).
Except that we could expose only the generic ones on the Bugzilla
Helper, which is used by all new bug filers until they get canconfirm.
Gerv
stuart...@gmail.com
> stuart...@gmail.com wrote:
> > 6. Even if we could magically trust that field to have correct
> > information, it's not sufficient to encode information about what a bug
> > affects: it's not uncommon for something to be broken before or after a
> > given version, meaning that there would have to be selections for every
> > possible OS range as well, which isn't practical.
>
> It sounds like you're saying "lets not make it better because it still
> wouldn't be perfect".
No, I'm saying that the argument that we should keep this field to
encode information about where a bug occurs ignores the fact that it
doesn't accurately reflect the information we'd need for most bugs that
aren't generic.
> The vast majority of bugs are either not OS specific,
This is definitely true.
> OS specific, or minor version OS specific.
This is not at all true in my experience for OS X. I would say that
easily the majority of all OS X bugs that are not true across all
versions are of the form "broken before version 10.x (or occasionally
10.x.y) or "broken after version 10.x(.y)". That's not an edge case,
it's a very common scenario. Having a field which we can use to encode
information about the *minority* of OS-specific bugs doesn't help, it
makes things worse; it would mean that you'd always have to look in two
places to get the information.
> The small minority of bugs that are "minor version specific across different
> minor version ranges" wouldn't be any worse off if we had an accurate way
> to specify the other three states.
So I disagree both with the assertion that it's a small minority and I
disagree that we wouldn't be worse off.
> The next-broadest category could be used for such bugs.
Given that many of the bugs I've seen are bugs that span major
versions, the next-broadest category is "Mac OS X", defeating the
entire purpose.
If the issue people have is that they don't want version-specifier
markers in other fields, then there need to be two new specific OS
fields: one for the first version affected, and one for the last, and
both need to have every version to the resolution we care about, plus
an 'unbounded' option for things like "broken before 10.4". Any
solution which tries to ignore ranges as a fringe case will fail for OS
X bugs.
stuart...@gmail.com
Sure, that addresses the "I can't trust this field" problem, but in the
section you quoted I'm saying that that's not sufficient, because even
if we can trust it it's not really a useful field as long as it just
has individual versions.
stuart...@gmail.com
Sure, that addresses the "I can't trust this field" problem, but in the
Gavin Sharp
> No, I'm saying that the argument that we should keep this field to
> encode information about where a bug occurs ignores the fact that it
> doesn't accurately reflect the information we'd need for most bugs that
> aren't generic.
>
I wasn't ignoring that fact, my proposal in the reply to Josh addresses
the fact that it currently isn't able to reflect the information we need
it to.
>> OS specific, or minor version OS specific.
>>
>
> This is not at all true in my experience for OS X. I would say that
> easily the majority of all OS X bugs that are not true across all
> versions are of the form "broken before version 10.x (or occasionally
> 10.x.y) or "broken after version 10.x(.y)". That's not an edge case,
> it's a very common scenario. Having a field which we can use to encode
> information about the *minority* of OS-specific bugs doesn't help, it
> makes things worse; it would mean that you'd always have to look in two
> places to get the information.
I don't understand what you mean by "look in two places". The two fields
would be next to each other on the show_bug.cgi page.
>> The next-broadest category could be used for such bugs.
>>
>
> Given that many of the bugs I've seen are bugs that span major
> versions, the next-broadest category is "Mac OS X", defeating the
> entire purpose.
>
Bugs that are broken in "10.3 or later" could be marked as being bugs in
10.3. I still don't see how we would be worse off.
> If the issue people have is that they don't want version-specifier
> markers in other fields, then there need to be two new specific OS
> fields: one for the first version affected, and one for the last, and
> both need to have every version to the resolution we care about, plus
> an 'unbounded' option for things like "broken before 10.4". Any
> solution which tries to ignore ranges as a fringe case will fail for OS
> X bugs.
Why would selecting the first version in which the bug appears not be an
adequate solution? I'm sure you'd agree that disjoint ranges (e.g.
broken in 10.1 and 10.3 but not 10.2) are extremely uncommon.
Gavin
Mike Shaver
> > Given that many of the bugs I've seen are bugs that span major
> > versions, the next-broadest category is "Mac OS X", defeating the
> > entire purpose.
>
> Bugs that are broken in "10.3 or later" could be marked as being bugs in
> 10.3. I still don't see how we would be worse off.
How do you find bugs that affect 10.4? See below.
> Why would selecting the first version in which the bug appears not be an
> adequate solution? I'm sure you'd agree that disjoint ranges (e.g.
> broken in 10.1 and 10.3 but not 10.2) are extremely uncommon.
You can't indicate "less than X" or "greater than X" unambiguously
that way, and searching degenerates badly: to find bugs that are
present in 10.4, you have end up having to search on all versions
(because a bug that stared in 10.1, 10.2, etc. could still be there in
10.4). Add to that the fact that the autodetection is broken, and the
version field is quite unlikely to be useful for actually finding bugs
that are specific to, or affect, a given version, so it's cost without
gain.
IMO, nothing that involves a change to bugzilla should keep us from
reverting this change now; when bugzilla can do better things, if
indeed they'll be better for us, we can revisit our whole story. The
perfect is beating the crap out of the good here, frustratingly.
Mike
stuart...@gmail.com
> Why would selecting the first version in which the bug appears not be an
> adequate solution? I'm sure you'd agree that disjoint ranges (e.g.
> broken in 10.1 and 10.3 but not 10.2) are extremely uncommon.
Because it makes it impossible to distinguish between these common
cases:
- A bug was introduced in 10.3 and fixed for 10.4, so it's 10.3-only
- A bug was introduced in 10.3 and remains unfixed, so it's a problem
for everyone 10.3+
Those have significant differences in terms of triage and testing, and
may even be handled completely differently (e.g., We had a few
10.2-only bugs in Camino, and we closed them out when we dropped 10.2
support without having found a workaround, which is not what we would
have done with bugs that were 10.2+). Something that couldn't capture
that difference would definitely not have been adequate for Camino, so
I wouldn't expect that it would be adequate for other products on OS X.
My comment about looking in two places was referring to the fact that
if the official way weren't adequate to encode the differences that we
care about, we'd just fall back to using the [10.x]-style summary
markers when we had to, meaning that sometimes the information we
needed would be in the OS field, and sometimes in the summary.
Gavin Sharp
> On 12/18/06, Gavin Sharp <gavin...@gmail.com> wrote:
>> > Given that many of the bugs I've seen are bugs that span major
>> > versions, the next-broadest category is "Mac OS X", defeating the
>> > entire purpose.
>>
>> Bugs that are broken in "10.3 or later" could be marked as being bugs in
>> 10.3. I still don't see how we would be worse off.
>
> How do you find bugs that affect 10.4? See below.
Indeed, my proposal assumes that "bugs that affect 10.4" is a less
useful and less commonly used query than "bugs that affect 10.4 only" or
"bugs that affect 10.4 or less only". Perhaps that's a bad assumption,
but making those last two queries possible without changing the fact
that the first isn't certainly seems like a win to me.
> IMO, nothing that involves a change to bugzilla should keep us from
> reverting this change now; when bugzilla can do better things, if
> indeed they'll be better for us, we can revisit our whole story. The
> perfect is beating the crap out of the good here, frustratingly.
I was not suggesting we avoid reverting this change and wait for a
change in Bugzilla. I was replying to Stuart's original claim that "Even
if we could magically trust that field to have correct information, it's
not sufficient to encode information about what a bug affects". My fault
for jumping in mid-thread with the assumption that everyone had read my
reply to Josh's original post, I guess.
Gavin
Gavin Sharp
> Gavin Sharp wrote:
>
>> Why would selecting the first version in which the bug appears not be an
>> adequate solution? I'm sure you'd agree that disjoint ranges (e.g.
>> broken in 10.1 and 10.3 but not 10.2) are extremely uncommon.
>>
>
> Because it makes it impossible to distinguish between these common
> cases:
> - A bug was introduced in 10.3 and fixed for 10.4, so it's 10.3-only
> - A bug was introduced in 10.3 and remains unfixed, so it's a problem
> for everyone 10.3+
>
Again, this sounds like "don't make it better because it won't be
perfect". The current scheme doesn't allow differentiating those bugs,
nor does the proposed "merge all OS X versions" solution. My proposed
solution doesn't fix that problem either, but it certainly doesn't make
it any worse. Until Bugzilla has the ability to track "doesn't affect
later OS versions" as a built-in field, you can use whatever techniques
you used to identify such bugs (whiteboard, summary) is before. The only
thing that changes is that you don't have to do that as often, because
now Bugzilla can handle more cases, and do so more accurately.
> My comment about looking in two places was referring to the fact that
> if the official way weren't adequate to encode the differences that we
> care about, we'd just fall back to using the [10.x]-style summary
> markers when we had to, meaning that sometimes the information we
> needed would be in the OS field, and sometimes in the summary.
The key point is "when you had to". If Bugzilla was improved, you'd need
to do that less and could rely on the version field more.
I have a feeling we're violently agreeing - Bugzilla needs to be fixed
so that it's version field is more useful. Perhaps it was not clear in
my that my replies here were made in the same context as my reply to
Josh's original post, in which I agreed that short-term the only
solution is to revert the change.
Gavin
stuart...@gmail.com
> Again, this sounds like "don't make it better because it won't be
> perfect". The current scheme doesn't allow differentiating those bugs,
> nor does the proposed "merge all OS X versions" solution. My proposed
> solution doesn't fix that problem either, but it certainly doesn't make
> it any worse. Until Bugzilla has the ability to track "doesn't affect
> later OS versions" as a built-in field, you can use whatever techniques
> you used to identify such bugs (whiteboard, summary) is before. The only
> thing that changes is that you don't have to do that as often, because
> now Bugzilla can handle more cases, and do so more accurately.
I just think if we are going to have (in the long term) changes to
Bugzilla to support both of the needs you described in your earlier
post (people like Josh and I, and people doing searches like you want
to) we should have a solution which meets all those needs, not a subset
of them. The reason I think a partial solution isn't really a win is
that I would expect one of two things to happen:
- duplicate information would have to be maintained (I would have to
mark 10.3+10.4-specific bugs as [10.3][10.4] in the summary to meet my
needs, but also set the OS version to 10.3 for your searches), or
- the above wouldn't happen, so the OS version wouldn't necessarily be
right for some bugs, so your searches wouldn't be right (undermining
your requirement that "bugs that are specific to an OS are easily and
consistently findable").
Realistically, probably a combination would happen. I'd end up doing
extra work some of the time, but forget other times, so your searches
would still be wrong. Under that scenario, I'm doing more work and
your queries still aren't working consistently.
> > My comment about looking in two places was referring to the fact that
> > if the official way weren't adequate to encode the differences that we
> > care about, we'd just fall back to using the [10.x]-style summary
> > markers when we had to, meaning that sometimes the information we
> > needed would be in the OS field, and sometimes in the summary.
>
> The key point is "when you had to". If Bugzilla was improved, you'd need
> to do that less and could rely on the version field more.
But right now I always know where the information I want is--at the
beginning of the summary, in one or more [10.x] markers. A system
where I always have to look in two places instead of one isn't a win
from my perspective. And if I always try to put the information in the
summary still so that I can just look at one thing, then that gets back
to the fact that in practice I'll forget to set the version field
because I won't ever use it, and it will increase the likelihood of
your queries being wrong.
> I have a feeling we're violently agreeing - Bugzilla needs to be fixed
> so that it's version field is more useful.
I'm not trying to be violently anything; I'm just trying to give my
input as a developer to help prevent someone from doing a bunch of
Bugzilla work along a path that I fear wouldn't make the field more
useful in practice. If people feel that a sub-version field will in
fact be useful for people even without devs using it, it's certainly
not a problem for me so long as there is also a more generic field I
can use for queries.
Robert Sayre
> If people feel that a sub-version field will in
> fact be useful for people even without devs using it, it's certainly
> not a problem for me so long as there is also a more generic field I
> can use for queries.
My two cents: the OS X version field consistently picks 10.3 even though
I am on 10.4, and I forget to unset it almost all of the time.
- Rob
bre...@mozilla.org
> That being said, I realize that implementing this suggestion in Bugzilla
> (and then getting it to b.m.o) is probably not a trivial undertaking,
> and isn't likely to happen soon enough to appease your frustration with
> the current situation. Given that the majority of Mac bugs are not
> isolated to a specific minor OS version, the best option left to fix
> this in a short time frame would probably be to to revert to a single
> "Mac" value for b.m.o's OS field, as you suggest.
Let's do that,then.
I'll mail marcia and comment in the bug.
> I don't like this
> change, because it conflicts with issue #2 above (and for all of the
> reasons I listed in my comments to bug 167002), but I guess it's only
> viable short-term solution to address your concerns. I suppose it's best
> to let your real-world Bugzilla annoyances trump my Bugzilla
> all-fields-should-be-set-correctly-all-the-time idealism :)
Idealism against human nature will lose every time.
/be
timeless
On Dec 20, 8:46 am, bren...@mozilla.org wrote:
> Gavin Sharp wrote:
> > That being said, I realize that implementing this suggestion in Bugzilla
> > (and then getting it to b.m.o) is probably not a trivial undertaking,
> > and isn't likely to happen soon enough to appease your frustration with
> > the current situation. Given that the majority of Mac bugs are not
> > isolated to a specific minor OS version, the best option left to fix
> > this in a short time frame would probably be to to revert to a single
> > "Mac" value for b.m.o's OS field, as you suggest.Let's do that,then.
>
> I'll mail marcia and comment in the bug.
>
> > I don't like this
> > change, because it conflicts with issue #2 above (and for all of the
> > reasons I listed in my comments to bug 167002), but I guess it's only
> > viable short-term solution to address your concerns. I suppose it's best
> > to let your real-world Bugzilla annoyances trump my Bugzilla
> > all-fields-should-be-set-correctly-all-the-time idealism :)Idealism against human nature will lose every time.
>
> /be
Bugzilla would guess OS X 10.4 correctly if reed/justdave would land my
patch. if that's the biggest problem this is just a matter of getting
signoff.
I've been unable to comment on this thread because the mac builds of
Camino and SeaMonkey and Firefox as of the last time i grabbed builds
would not let me enter nany text into <textarea>s, and GMail (rich
view) would simply give me an infinite number of slow script dialogs.
i have no idea if that's specific to me running 10.3 or just some
feature of the new Cairo+reflow code or what.
as for writing a message from windows, i tried 3 or 4 times today and
each time i try to find "brendan" the 'd' isn't found which leads to an
assertion which leads to a dialog where typing 'a' means abort. which
means that since i foolishly assume ctrl-f brendan, or / brendan or '
brendan will find what i want (or at least not crash fatally), I
repeatedly fail to get to this message in any way.
note that we're trying to get bugzilla.mozilla.org to move back to a
model where it updates regularly so we could actually have improvements
for things instead of the Camino model where you get a new version
every 2 years.
I'm hoping that a number of the proposals gavin and i have made will
actually be able to make it to Bugzilla soon enough to help people who
have been complaining.
I'm sorry if my response came late. instead of arguing with people who
wouldn't listen to me (and it's clear no one here will listen to me,
thank you all). I've been working on designing UIs and other features
which would address the core problems.