Closed Bug 1660900 Opened 5 months ago Closed 2 days ago

Please don't close bugs as verified fixed when only one part is fixed

Categories

(Firefox :: Untriaged, enhancement)

enhancement

Tracking

()

RESOLVED INVALID

People

(Reporter: erwinm, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

A number of bugs have been Closed VERIFIED FIXED when only part of the bug has been fixed.

Actual results:

For example, bug 1629303 concerned epilepsy triggers when clicking the megabar. I'm not the original reporter, and don't know how much the partial fixes have helped.

For example, bug 1610081 concerned migraine triggers due to the redesign of about:preferences and about:addons several versions back. I'm the original reporter there, and can confirm the partial fixes are not nearly enough, so I had to revive it as bug 1658601.

Expected results:

When multiple fixes are required, either (a) spin off separate bug reports for each fix, or (b) introduce some kind of PARTFIXED, but (c) please don't close bugs as VERIFIED FIXED after only one part is fixed.

Component: General → Untriaged
Product: bugzilla.mozilla.org → Firefox

Hey MarjaE and thank you for the enhancement request. If you'd allow me, I'll give my oppinion related to the above suggestions.

Generally speaking, a bug verification has two purposes: first to make sure that it does what the fix describes doing and secondly to ensure that there are no regressions introduced by the fix. Obviouslly, for beeing able to follow through with a verification, the following are required: having the required knowledge, capacity and hardware to reproduce the bug on affected builds and then not reproduce the bug on fixed builds. As you are aware, in software developement it is expected that sometimes, there is a disjoint betwen what the specification requests - here the bug report - , what the implementation actually does - the fix - and what the testing people can or actually test - the verification - . Imagine this gap getting emphased by not having the exact particularities of the person who reported the issue and who was not part of the implementation/verification process.
Therefore, particularly in the accessibility area, there's a certain gap of specialized people who can or would do verifications, so it is often the case that a fix that is deemed as complete implemented and verified as such, only to have it spin up later in follow-ups as a specialized eye was thrown over.

Given the above context, everybody expects that a resolved fixed issue contains a patch or a series of patches that fix a problem or a part of the problem. Often is the case in which multiple issues are present in a bug report and follow-ups are spinned starting with the initial report but there are also cases in which the spin-ofs can happen at a later time after the initial fix. Hence a complete resolved bug might turn partial fixed at a later date, but having a status to reflect that would not affect any follow-up fixes or follow-up verifications, since those are going to be handled in the spin-offs anyways.

Overall, it is my oppinion that introducing intermediary statuses would only complicate things, since all the bugs might be part-fixed or part verified depending of the point of view or depending of the timeframe.

Hoping that the above wall of text makes sense, please feel free to add more context or clarification if I missunderstood anything.

Okay, thank you.

Sounds like this is clarified.

Status: UNCONFIRMED → RESOLVED
Closed: 2 days ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.