"How a 23-year-old first-time Firefox coder fixed a 22-year-old bug
Tiny text boxes, lingering on screens like ghosts, exorcised after 2
decades."
https://arstechnica.com/gadgets/2023/10/22-year-old-firefox-tooltip-bug-fixed-in-a-few-lines-offering-hope-to-us-all/

"Back in June 2002, Ubuntu founder Mark Shuttleworth was experiencing
space for the first time, the Department of Justice's antitrust case
against Microsoft was reaching its final arguments, and Adam Price,
using what was then called Mozilla on a Mac, had an issue with
persistent tooltips."

""If I mouseover a toolbar link, and wait for a second, a little yellow
box with the description of the link appears. If I now use command-tab
to move Mozilla to the background, the little yellow box stays there, in
the foreground. The only way to get rid of it is to put mozilla in the
foreground again, and move the mouse off the toolbar," Price wrote on
June 2. There were a few other bugs related to this issue, but Price set
down a reproducible issue, confirmed by many others in the weeks to
come—and months to come, years to come, and more than two decades to come."

Lynn

Lynn McGuire <lynnmcguire5@gmail.com> wrote:

> "How a 23-year-old first-time Firefox coder fixed a 22-year-old bug
> Tiny text boxes, lingering on screens like ghosts, exorcised after 2
> decades."
>
> https://arstechnica.com/gadgets/2023/10/22-year-old-firefox-tooltip-bug-fixed-in-a-few-lines-offering-hope-to-us-all/
>
> "Back in June 2002, Ubuntu founder Mark Shuttleworth was experiencing
> space for the first time, the Department of Justice's antitrust case
> against Microsoft was reaching its final arguments, and Adam Price,
> using what was then called Mozilla on a Mac, had an issue with
> persistent tooltips."
>
> ""If I mouseover a toolbar link, and wait for a second, a little yellow
> box with the description of the link appears. If I now use command-tab
> to move Mozilla to the background, the little yellow box stays there, in
> the foreground. The only way to get rid of it is to put mozilla in the
> foreground again, and move the mouse off the toolbar," Price wrote on
> June 2. There were a few other bugs related to this issue, but Price set
> down a reproducible issue, confirmed by many others in the weeks to
> come—and months to come, years to come, and more than two decades to come."
>
> Lynn

Mozilla exerts no effort or resources to review ancient bug reports to
check if they can still be reproduced on the latest supported versions,
or to even investigate. There are plenty of ancient bug tickets.
Mozilla should decide if they aren't going to expend resources to verify
and address the old tickets to then summarily close them either as
non-reproducible or no longer applicable. Ancient tickets are against
ancient versions of Mozilla products that have long expired for support.
Then let users open new tickets even on the same issue, but reproducible
on the latest versions. Bugzilla should automatically expire or archive
tickets that are too old. It's just noise that no dev is going to
address on the latest versions.

New updates to old tickets rarely get reviewed. Close the old ones,
especially those that can no longer be reproduced on latest versions,
and have a fresh view when users open new tickets even on an old
problem. It gets confusing when you're reading through tickets to see
this one is a duplicate of that one, but that one is a duplicate of
another one, and so one, and sometimes it gets circular to reopen a
ticket that was previously closed as a duplicate. And frustrating to
check before opening a ticket if the problem has been reported before,
but an old ticket is decades old on an ancient version, and there has
been no movement, so the chances of you spurring action on the old
ticket are very low.

On 10/12/23 08:39 PM, this is what VanguardLH wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>
>> "How a 23-year-old first-time Firefox coder fixed a 22-year-old bug
>> Tiny text boxes, lingering on screens like ghosts, exorcised after 2
>> decades."
>>
>> https://arstechnica.com/gadgets/2023/10/22-year-old-firefox-tooltip-bug-fixed-in-a-few-lines-offering-hope-to-us-all/
>>
>> "Back in June 2002, Ubuntu founder Mark Shuttleworth was experiencing
>> space for the first time, the Department of Justice's antitrust case
>> against Microsoft was reaching its final arguments, and Adam Price,
>> using what was then called Mozilla on a Mac, had an issue with
>> persistent tooltips."
>>
>> ""If I mouseover a toolbar link, and wait for a second, a little yellow
>> box with the description of the link appears. If I now use command-tab
>> to move Mozilla to the background, the little yellow box stays there, in
>> the foreground. The only way to get rid of it is to put mozilla in the
>> foreground again, and move the mouse off the toolbar," Price wrote on
>> June 2. There were a few other bugs related to this issue, but Price set
>> down a reproducible issue, confirmed by many others in the weeks to
>> come—and months to come, years to come, and more than two decades to come."
>>
>> Lynn
>
> Mozilla exerts no effort or resources to review ancient bug reports to
> check if they can still be reproduced on the latest supported versions,
> or to even investigate. There are plenty of ancient bug tickets.
> Mozilla should decide if they aren't going to expend resources to verify
> and address the old tickets to then summarily close them either as
> non-reproducible or no longer applicable. Ancient tickets are against
> ancient versions of Mozilla products that have long expired for support.
> Then let users open new tickets even on the same issue, but reproducible
> on the latest versions. Bugzilla should automatically expire or archive
> tickets that are too old. It's just noise that no dev is going to
> address on the latest versions.
>
> New updates to old tickets rarely get reviewed. Close the old ones,
> especially those that can no longer be reproduced on latest versions,
> and have a fresh view when users open new tickets even on an old
> problem. It gets confusing when you're reading through tickets to see
> this one is a duplicate of that one, but that one is a duplicate of
> another one, and so one, and sometimes it gets circular to reopen a
> ticket that was previously closed as a duplicate. And frustrating to
> check before opening a ticket if the problem has been reported before,
> but an old ticket is decades old on an ancient version, and there has
> been no movement, so the chances of you spurring action on the old
> ticket are very low.
+1
--
Linux Mint 21.2 Cinnamon
Al

On 12 Oct 2023 19:39:00 -0500 VanguardLH wrote:
>Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>
>> "How a 23-year-old first-time Firefox coder fixed a 22-year-old bug
>> Tiny text boxes, lingering on screens like ghosts, exorcised after 2
>> decades."
>>
>>
>> https://arstechnica.com/gadgets/2023/10/22-year-old-firefox-tooltip-bug-fixed-in-a-few-lines-offering-hope-to-us-all/
>>
>> "Back in June 2002, Ubuntu founder Mark Shuttleworth was experiencing
>> space for the first time, the Department of Justice's antitrust case
>> against Microsoft was reaching its final arguments, and Adam Price,
>> using what was then called Mozilla on a Mac, had an issue with
>> persistent tooltips."
>>
>> ""If I mouseover a toolbar link, and wait for a second, a little yellow
>> box with the description of the link appears. If I now use command-tab
>> to move Mozilla to the background, the little yellow box stays there, in
>> the foreground. The only way to get rid of it is to put mozilla in the
>> foreground again, and move the mouse off the toolbar," Price wrote on
>> June 2. There were a few other bugs related to this issue, but Price set
>> down a reproducible issue, confirmed by many others in the weeks to
>> come—and months to come, years to come, and more than two decades to
>> come."
>>
>> Lynn
>
>Mozilla exerts no effort or resources to review ancient bug reports to
>check if they can still be reproduced on the latest supported versions,
>or to even investigate. There are plenty of ancient bug tickets.
>Mozilla should decide if they aren't going to expend resources to verify
>and address the old tickets to then summarily close them either as
>non-reproducible or no longer applicable. Ancient tickets are against
>ancient versions of Mozilla products that have long expired for support.
>Then let users open new tickets even on the same issue, but reproducible
>on the latest versions. Bugzilla should automatically expire or archive
>tickets that are too old. It's just noise that no dev is going to
>address on the latest versions.
>
>New updates to old tickets rarely get reviewed. Close the old ones,
>especially those that can no longer be reproduced on latest versions,
>and have a fresh view when users open new tickets even on an old
>problem. It gets confusing when you're reading through tickets to see
>this one is a duplicate of that one, but that one is a duplicate of
>another one, and so one, and sometimes it gets circular to reopen a
>ticket that was previously closed as a duplicate. And frustrating to
>check before opening a ticket if the problem has been reported before,
>but an old ticket is decades old on an ancient version, and there has
>been no movement, so the chances of you spurring action on the old
>ticket are very low.

I disagree that bugs should be closed /without verifying that they no
longer exist/. But that verification requires effort and if it's
low-priority or rarely occurs there are more important things for the
developers to do. BZ has adequate sort and selection facilities if you
want to exclude old bugs. I usually start by just sorting hits into
reverse bug number order.

I have often been asked, as originator of a bug, whether I can still
reproduce it. Often my answer is: I don't have the means to try, but I
think it should be closed because... And it is.

And finally, these minor bugs can hook new young developers - as happened
in this case.

One of the most irritating features of thr Fenix development (Fx on
Android) was that their bug system - when it was on github - closed bugs
after a short period of inactivity. I gave up raising bugs, or commenting
on them. I certainly didn't waste effort on producing long STRs.
--
(Remove numerics from email address)

On Thu, 12 Oct 2023 19:39:00 -0500, VanguardLH wrote:
> Ancient tickets are against
> ancient versions of Mozilla products that have long expired for support.
>

True, and that's consistent with my bugaboo: user-level documents
that explain how to do things very often don't match the actual
product, because of Mozilla's frequent just-because-we-can UI
changes, and Mozilla's documents give no hint of what software
versions they apply to.

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

On 10/13/23 10:25 AM, Stan Brown wrote:
> On Thu, 12 Oct 2023 19:39:00 -0500, VanguardLH wrote:
>> Ancient tickets are against
>> ancient versions of Mozilla products that have long expired for support.
>>
>
> True, and that's consistent with my bugaboo: user-level documents
> that explain how to do things very often don't match the actual
> product, because of Mozilla's frequent just-because-we-can UI
> changes, and Mozilla's documents give no hint of what software
> versions they apply to.

ALL such things -- reviews, questions, answers, instructions, prayers --
should be dated and branded and versioned. It's bad enough when
developers simply write wrong instructions, but it's worse when they
chew you out for bothering them with such trivia.

That means YOU, Netscape.99/linux assholes.

--
Cheers, Bev
"I don't need instructions, I have a hammer."
-- T.W. Wier

Stan Brown <the_stan_brown@fastmail.fm> wrote:

> VanguardLH wrote:
>
>> Ancient tickets are against ancient versions of Mozilla products that
>> have long expired for support.
>
> True, and that's consistent with my bugaboo: user-level documents
> that explain how to do things very often don't match the actual
> product, because of Mozilla's frequent just-because-we-can UI
> changes, and Mozilla's documents give no hint of what software
> versions they apply to.

Working in QA at corporations producing enterprise-grade software (very
expensive per seat), there was the Functional Specification document,
and the Engineering Specification document. The first told you how the
product was expected to work. The second told how it actually worked.
One was a photo. The other was an X-ray. Of course, that is in a
company that had a Documents group separate of the Development group
separate of the QA group, and we all had to communicate with each other.
Not developers writing their own functional and engineering specs.

Be great if Mozilla had those, or equivalent, documents. Do they? I
don't mean deciphering the code. I mean what the code was expected to
do before ever written.

VanguardLH graced us with on 10/14/2023 3:17 PM:
> Stan Brown <the_stan_brown@fastmail.fm> wrote:
>
>> VanguardLH wrote:
>>
>>> Ancient tickets are against ancient versions of Mozilla products that
>>> have long expired for support.
>> True, and that's consistent with my bugaboo: user-level documents
>> that explain how to do things very often don't match the actual
>> product, because of Mozilla's frequent just-because-we-can UI
>> changes, and Mozilla's documents give no hint of what software
>> versions they apply to.
>
> Working in QA at corporations producing enterprise-grade software (very
> expensive per seat), there was the Functional Specification document,
> and the Engineering Specification document. The first told you how the
> product was expected to work. The second told how it actually worked.
> One was a photo. The other was an X-ray. Of course, that is in a
> company that had a Documents group separate of the Development group
> separate of the QA group, and we all had to communicate with each other.
> Not developers writing their own functional and engineering specs.
>
> Be great if Mozilla had those, or equivalent, documents. Do they? I
> don't mean deciphering the code. I mean what the code was expected to
> do before ever written.

As I recall, they did and even adhered to ISO 9000 specs. That all
changed after AOL sent them out on their own. I don't recall the date it
actually stopped but I'm fairly certain it was just before or soon after
Google went to their quick release cycle.

--
Sailfish
CDC Covid19 Trends: https://www.facebook.com/groups/624208354841034
Rare Mozilla Stuff: http://tinyurl.com/z86x3sg

On 15/10/2023 12:20, Sailfish wrote:
> VanguardLH graced us with on 10/14/2023 3:17 PM:
>> Stan Brown <the_stan_brown@fastmail.fm> wrote:
>>
>>> VanguardLH wrote:
>>>
>>>> Ancient tickets are against ancient versions of Mozilla products that
>>>> have long expired for support.
>>> True, and that's consistent with my bugaboo: user-level documents
>>> that explain how to do things very often don't match the actual
>>> product, because of Mozilla's frequent just-because-we-can UI
>>> changes, and Mozilla's documents give no hint of what software
>>> versions they apply to.
>>
>> Working in QA at corporations producing enterprise-grade software (very
>> expensive per seat), there was the Functional Specification document,
>> and the Engineering Specification document.  The first told you how the
>> product was expected to work.  The second told how it actually worked.
>> One was a photo.  The other was an X-ray.  Of course, that is in a
>> company that had a Documents group separate of the Development group
>> separate of the QA group, and we all had to communicate with each other.
>> Not developers writing their own functional and engineering specs.
>>
>> Be great if Mozilla had those, or equivalent, documents.  Do they?  I
>> don't mean deciphering the code.  I mean what the code was expected to
>> do before ever written.
>
> As I recall, they did and even adhered to ISO 9000 specs. That all
> changed after AOL sent them out on their own. I don't recall the date it
> actually stopped but I'm fairly certain it was just before or soon after
> Google went to their quick release cycle.
>
I've been using ISO 9000 et seq. for most of this century, it's not a
panacea.

ISO 9000 and it's descendants merely mean that there is an auditable
process in place, it says *nothing* about the accuracy, usefulness,
sensibility, and so on, of that process, just that it fits the parameters.

Bugs, and stupidity, still happen, and if the stupid is at the top...

Cheers,
Gary B-)

On 10/14/23 9:20 PM, Gary R. Schmidt wrote:
> On 15/10/2023 12:20, Sailfish wrote:
>> VanguardLH graced us with on 10/14/2023 3:17 PM:
>>> Stan Brown <the_stan_brown@fastmail.fm> wrote:
>>>
>>>> VanguardLH wrote:
>>>>
>>>>> Ancient tickets are against ancient versions of Mozilla products that
>>>>> have long expired for support.
>>>> True, and that's consistent with my bugaboo: user-level documents
>>>> that explain how to do things very often don't match the actual
>>>> product, because of Mozilla's frequent just-because-we-can UI
>>>> changes, and Mozilla's documents give no hint of what software
>>>> versions they apply to.
>>>
>>> Working in QA at corporations producing enterprise-grade software (very
>>> expensive per seat), there was the Functional Specification document,
>>> and the Engineering Specification document.  The first told you how the
>>> product was expected to work.  The second told how it actually worked.
>>> One was a photo.  The other was an X-ray.  Of course, that is in a
>>> company that had a Documents group separate of the Development group
>>> separate of the QA group, and we all had to communicate with each other.
>>> Not developers writing their own functional and engineering specs.
>>>
>>> Be great if Mozilla had those, or equivalent, documents.  Do they?  I
>>> don't mean deciphering the code.  I mean what the code was expected to
>>> do before ever written.
>>
>> As I recall, they did and even adhered to ISO 9000 specs. That all
>> changed after AOL sent them out on their own. I don't recall the date it
>> actually stopped but I'm fairly certain it was just before or soon after
>> Google went to their quick release cycle.
>>
> I've been using ISO 9000 et seq. for most of this century, it's not a
> panacea.
>
> ISO 9000 and it's descendants merely mean that there is an auditable
> process in place, it says *nothing* about the accuracy, usefulness,
> sensibility, and so on, of that process, just that it fits the parameters.

It was just coming up when I was in QA at Magellan. Boss printed up
huge manuals for management just because he liked to show the flag and
annoy them. I was shocked that it was just record-keeping, not anything
actually aimed at improving quality.
> Bugs, and stupidity, still happen, and if the stupid is at the top...

Stupid at the top provides a wider range of victims.

--
Cheers, Bev
Nothing is so stupid that you can't find somebody who
did it at least once if you look hard enough.

Gary R. Schmidt graced us with on 10/14/2023 9:20 PM:
> On 15/10/2023 12:20, Sailfish wrote:
>> VanguardLH graced us with on 10/14/2023 3:17 PM:
>>> Stan Brown <the_stan_brown@fastmail.fm> wrote:
>>>
>>>> VanguardLH wrote:
>>>>
>>>>> Ancient tickets are against ancient versions of Mozilla products that
>>>>> have long expired for support.
>>>> True, and that's consistent with my bugaboo: user-level documents
>>>> that explain how to do things very often don't match the actual
>>>> product, because of Mozilla's frequent just-because-we-can UI
>>>> changes, and Mozilla's documents give no hint of what software
>>>> versions they apply to.
>>>
>>> Working in QA at corporations producing enterprise-grade software (very
>>> expensive per seat), there was the Functional Specification document,
>>> and the Engineering Specification document. The first told you how the
>>> product was expected to work. The second told how it actually worked.
>>> One was a photo. The other was an X-ray. Of course, that is in a
>>> company that had a Documents group separate of the Development group
>>> separate of the QA group, and we all had to communicate with each other.
>>> Not developers writing their own functional and engineering specs.
>>>
>>> Be great if Mozilla had those, or equivalent, documents. Do they? I
>>> don't mean deciphering the code. I mean what the code was expected to
>>> do before ever written.
>>
>> As I recall, they did and even adhered to ISO 9000 specs. That all
>> changed after AOL sent them out on their own. I don't recall the date
>> it actually stopped but I'm fairly certain it was just before or soon
>> after Google went to their quick release cycle.
>>
> I've been using ISO 9000 et seq. for most of this century, it's not a
> panacea.
>
> ISO 9000 and it's descendants merely mean that there is an auditable
> process in place, it says *nothing* about the accuracy, usefulness,
> sensibility, and so on, of that process, just that it fits the parameters.
>
> Bugs, and stupidity, still happen, and if the stupid is at the top...
>
I never said it was. I was involved with ISO 9000 back in ancient times,
the 1990s. Back then, software development had very few standards nor
development, QA checks&balances like code reviews, code owners, (module,
limit, negative, stress testing, &c.) ISO 9000 also required
organizations to document their processes which helped establish
baseline methods.

Still, as you stated, it didn't prevent bugs but it did change the
development process and methods for the better, imo. However, the
processes it implemented literally slowed a lot of development
significantly which is why companies like Mozilla backed away from more
the full implementation they had been using.

--
Sailfish
CDC Covid19 Trends: https://www.facebook.com/groups/624208354841034
Rare Mozilla Stuff: http://tinyurl.com/z86x3sg