Closed Bug 1443764 Opened 6 years ago Closed 6 years ago

Add parity-* keywords to replace the current parity-* whiteboard strings

Categories

(bugzilla.mozilla.org :: General, enhancement)

Product:
bugzilla.mozilla.org
Component:
General
Version:
Production
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jwatt, Assigned: jwatt)

Details

Attachments

(1 file)

Greasemonkey script
(deleted), text/plain
Details 
Right now we have a bunch of adhoc whiteboard strings for parity with other browser engines. Unfortunately, the strings that we currently use have different variants for the same thing. For example, we have both "compat-Chrome" and "compat-Blink", and we have both "compat-Safari" and "compat-Webkit".

This variability make it much harder to construct bugzilla queries. For example, if I want a list of all bugs for features that are already implemented in Chrome, Safari and Edge, then I can't just search for bugs with "parity-blink" and "parity-webkit" and "parity-edge". I have to figure out how to construct a more complex query with OR conditionals.

Having standard keywords would prevent this issue from occurring.
To get a list of the current parity-* flags related to the Web platform and how often they're used I made the following bugzilla query:

https://bugzilla.mozilla.org/buglist.cgi?f0=status_whiteboard&o0=substring&v0=parity-&query_format=advanced&product=Core&resolution=---&limit=0

I then used the "Change Columns" link to add the "Whiteboard" column and, once the results had loaded, I ran the following script in the web console:

const whiteboardElements = document.querySelectorAll(".bz_status_whiteboard_column");
const whiteboards = Array.from(whiteboardElements).map(td => td.textContent.trim());
let parityFlagsCounts = {};
for (let whiteboard of whiteboards) {
    for (let parityFlag of whiteboard.match(/(parity-\w+)/g) || []) {
        parityFlag = parityFlag.toLowerCase();
        parityFlagsCounts[parityFlag] =
            parityFlagsCounts[parityFlag] ? parityFlagsCounts[parityFlag] + 1 : 1;
    }
}
const parityFlags = Object.keys(parityFlagsCounts).sort((a, b) => a.toLowerCase() > b.toLowerCase());
let msg = "";
for (let flag of parityFlags) {
    msg += flag + ": " + parityFlagsCounts[flag] + "\n";
}
console.log(msg);
I've grouped the results from the output from my script under four suggested keyword names (numbers are the number of bugs these flags appear on):

compat-blink
  parity-blink: 29
  parity-chrome: 213
  parity-opera: 36

compat-edge
  parity-edge: 76

compat-ie (we only care about the final version, 11, nowadays)
  parity-ie: 90
  parity-ie10: 1
  parity-ie11: 1
  parity-ie8: 3
  parity-ie9: 1

compat-webkit
  parity-safari: 31
  parity-webkit: 39
For completeness, there were five other parity-* flags in the results:

compat with ourself? I guess we could add another couple of keywords, but the use count is only 1 so probably not worth it.
  parity-desktop: 1
  parity-mobile: 1

defunct
  parity-opera12: 1
  parity-presto: 2

again, not worth a keyword I think
  parity-mathjax: 1
CC'ing everyone who's set a "parity-*" flag in the whiteboard field in the last 2 months.
:jwatt, thanks for doing the research on this. I can set up the whiteboard tags for future assignment, and have a script I can modify which will go through the bugs with those tags and move them to the new keyword. 

If I don't hear back from the people cc'd by next week (Monday, March 12) I'll get the script code reviewed and update the affected bugs.
Assignee: nobody → ehumphries
Flags: needinfo?(jwatt)
Sounds good to me. I've also sent an email to mozilla.dev.platform to make sure there are no objections.
Flags: needinfo?(jwatt)
(In reply to Jonathan Watt [:jwatt] (needinfo? me) from comment #3)
> defunct
>   parity-opera12: 1
>   parity-presto: 2

Actually Presto is still used in Opera Mini, which has about 3% global usage share according to caniuse.com (I'm not sure where they get their stats, or if presto share is trending up or down). I guess we could add a compat-presto keyword as well, although we only have two bugs with parity-presto.
compat (and your email) implies only Web Feature Compatibility. 'Parity' implies partity with things that may not be exposed to the web, such as security features (Memory Partitioning, Control Flow Integrity, etc).  Are you okay with these issues be tagged with compat- keywords?
Thanks for filing this, I was thinking of requesting something similar a few weeks ago.

(In reply to Jonathan Watt [:jwatt] (needinfo? me) from comment #4)
> CC'ing everyone who's set a "parity-*" flag in the whiteboard field in the
> last 2 months.

Not sure why I wasn't included since I used these whiteboard tags in bug 1437969. I notice now that comment 1 is only lists the Core product so I guess that search was limited to Core.

(In reply to Jonathan Watt [:jwatt] (needinfo? me) from comment #0)
> Unfortunately, the strings that we currently use have
> different variants for the same thing. For example, we have both
> "compat-Chrome" and "compat-Blink", and we have both "compat-Safari" and
> "compat-Webkit".

IMO this is over-simplifying when it comes to UI-related features since the engine and the front-end don't always go together (e.g. Opera vs. Chrome). Maybe this could work for Core products which don't have much UI but I think it may be confusing for UI features like in Firefox and some of Toolkit which share the same keywords. If we're going to end up wanting the browser name versions for the UI-related features, it may make sense to unify on using the browser names, instead of engine names.

Also, I think parity-* makes more sense for UI features than compat-* (since they're usually not about compatibility) so I would prefer retaining the old prefix.

IMO a solution that would work better for all Firefox products would be:
* parity-chrome
* parity-opera (or just ignore opera)
* parity-edge
* parity-ie
* parity-safari
TL;DR I'm fine with parity-[browser name] rather than compat-[engine name] I think.

The issue that prompted me to file this was wanting to know which Web platform features are being held up from widespread use by Firefox because it's the last browser to implement a given feature (bad for the Web, and bad for our reputation with devs/early adopters). Hence why I proposed compat-[engine name] keywords rather than parity-[browser name] keywords to see how that might/might not fly.

I would be valuable to be able to find browser engine parity issues that are not actually web platform functionalities (such as security features) though, I agree. Having a separate keyword for that would probably cause more confusion though, and there are likely few enough of them that it's okay to use the same keyword as for web compat issues from my perspective. So yeah, parity-* probably is better than compat-*.

It's also true that the same issue with various flag variants being used for the same thing is an issue outside of Core. We should ideally "fix" the problems with using the whiteboard for everyone, but I was just worried that if the scope of the changes got too big we might not get agreement and end up doing nothing. Ideally I'd like to have the engine name in the keywords for my use cases, but I don't like the idea of having both engine name and browser name keywords since then we're back to having the problem of people using the wrong thing again. So on balance I guess I'd rather have parity-[browser name] than both parity-[browser name] and parity-[engine name]. Filtering on bugzilla product/component as appropriate should usually be sufficient to distinguish between engine issues and other issues.

My 2c anyways.
It's worse than I thought! cpeterson just pointed out to me that we also have plenty of instances of *-parity (as opposed to parity-*). Assuming we do end up adding new keywords, we should also convert those too.
I repeated comment 1 to search across all products and components (not just Core) using:

https://bugzilla.mozilla.org/buglist.cgi?f0=status_whiteboard&o0=anywordssubstr&v0=parity- -parity&query_format=advanced&resolution=---&limit=0

And used the following modified script to pull out instances of both parity-* and *-parity:

const whiteboardElements = document.querySelectorAll(".bz_status_whiteboard_column");
const whiteboards = Array.from(whiteboardElements).map(td => td.textContent.trim());
let parityFlagsCounts = {};
for (let whiteboard of whiteboards) {
    for (let parityFlag of whiteboard.match(/(parity-\w+)|(\w+-parity)/g) || []) {
        parityFlag = parityFlag.toLowerCase();
        parityFlagsCounts[parityFlag] =
            parityFlagsCounts[parityFlag] ? parityFlagsCounts[parityFlag] + 1 : 1;
    }
}
const parityFlags = Object.keys(parityFlagsCounts).sort((a, b) => a.toLowerCase() > b.toLowerCase());
let msg = "";
for (let flag of parityFlags) {
    msg += flag + ": " + parityFlagsCounts[flag] + "\n";
}
console.log(msg);

That results in the list:

blink-parity: 1
chrome-parity: 6
edge-parity: 1
fx2-parity: 4
ie-parity: 3
ie11-parity: 1
kq-parity: 1
mxr-parity: 3
oe-parity: 3
opera-parity: 1
parity-all: 1
parity-android: 1
parity-blink: 34
parity-camino: 1
parity-chrome: 309
parity-desktop: 5
parity-edge: 89
parity-emacs: 1
parity-fennec: 3
parity-ffos: 1
parity-firefox: 2
parity-flash: 1
parity-gmail: 2
parity-ie: 119
parity-ie10: 1
parity-ie11: 1
parity-ie8: 2
parity-ie9: 1
parity-ios: 1
parity-konversation: 3
parity-mathjax: 1
parity-mibbit: 1
parity-mobile: 1
parity-oe: 6
parity-opera: 58
parity-opera12: 1
parity-outlook: 1
parity-postbox: 3
parity-presto: 2
parity-safari: 51
parity-seamonkey: 1
parity-stock: 2
parity-trident: 1
parity-webkit: 48
parity-windows: 1
safari-parity: 4
So I propose:

parity-chrome
  parity-chrome: 309
  parity-blink: 34
  chrome-parity: 6
  blink-parity: 1

parity-safari
  parity-safari: 51
  parity-webkit: 48
  safari-parity: 4

parity-ie
  parity-ie: 119
  parity-ie10: 1
  parity-ie11: 1
  parity-ie8: 2
  parity-ie9: 1
  parity-trident: 1
  ie-parity: 3
  ie11-parity: 1

parity-edge
  parity-edge: 89
  edge-parity: 1

parity-opera
  parity-opera: 26
  opera-parity: 1

parity-opera-mini
  parity-presto opera: 15
  parity-opera12: 1
For the record, that leaves the following as whiteboard flags:

parity-camino: 1 (Discontinued)
fx2-parity: 4
parity-android: 1
parity-desktop: 5
parity-mobile: 1
kq-parity: 1  (Konqueror/KHTML - not worth tracking)
mxr-parity: 3
oe-parity: 3  (Outlook Express - discontinued)
parity-all: 1 (Email software parity)
parity-emacs: 1
parity-fennec: 3
parity-ffos: 1
parity-firefox: 2 (SeaMonkey parity)
parity-flash: 1
parity-gmail: 2
parity-ios: 1
parity-konversation: 3 (ChatZilla parity)
parity-mathjax: 1
parity-mibbit: 1
parity-oe: 6
parity-outlook: 1
parity-postbox: 3
parity-seamonkey: 1
parity-stock: 2
parity-windows: 1
I went through the [parity-opera] bugs and changed those that are Presto parity issues to [parity-presto opera] so that we can distinguish between them in any automated rewrite.
Over to you, Emma. I send another email to mozilla.dev.platform yesterday to notify people about the change in the proposal. Assuming there are no follow-up objections I think you can go ahead with adding the keywords and writing a conversion script.
Flags: needinfo?(ehumphries)
Adding new keywords and descriptions (so I have them to move bugs into).

parity-chrome: This bug is related to feature parity with Chrome
parity-safari: This bug is related to feature parity with Safari
parity-ie:     This bug is related to feature parity with Internet Explorer
parity-edge:   This bug is related to feature parity with Microsoft Edge
parity-opera:  This bug is related to feature parity with Opera
parity-opera-mini: This bug is related to feature parity with Opera Mini
parity-other-browsers: This bug is related to feature parity with another browser (not Chrome, Safari, IE, Edge, Opera, or Opera Mini)
(In reply to Emma Humphries, Bugmaster ☕️ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #17)
> parity-other-browsers: This bug is related to feature parity with another browser (not Chrome, Safari, IE, Edge, Opera, or Opera Mini)

Note that I don't think Jonathan was asking for this and I don't think we need to migrate the whiteboard tags that are mentioned in comment 14, especially since many of those are not for browsers. IMO we should only migrate the ones in comment 13.
Yeah, since there's no real use of other relevant whiteboard flags I personally would remove that one until/unless the need arises. Keeping the keywords to a minimum avoids autocomplete clutter which is nice.
I've deleted that catch-all keyword. Working on the script.
Flags: needinfo?(ehumphries)
Dylan, is this something Israel could help with? I'm not going to have time to finish this before tomorrow.
Flags: needinfo?(dylan)
Emma, can you tell me where and how does rewriting scripts run? Are there any other examples of such scripts in bugzilla?
Flags: needinfo?(ehumphries)
:jwatt, here's an example I wrote in nodejs for editing whiteboard tags.
Flags: needinfo?(ehumphries)
I'm not sure I understand the task required here?
Flags: needinfo?(dylan)
(In reply to Dylan Hardison [:dylan] (he/him) from comment #24)
> I'm not sure I understand the task required here?

Go through the bugs from the query above, edit the whiteboard tag field to remove the tags mentioed, and add a keyword instead. 

For each new keyword, there's a list of whiteboard tags for which that'd replace.
Assignee: ehumphries → jwatt
I'm temporarily adding :jwatt to the list of 'no-bugspam' users so they can edit these bugs with his greasemonkey script at https://pastebin.mozilla.org/9084465 and check the results by hand. 

When they are done, they will needinfo me and I'll remove them from the list of 'no-bugspam' users.
All done. Can you remove me from the 'no-bugspam' users please?
Flags: needinfo?(ehumphries)
Done! Thank you.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(ehumphries)
Resolution: --- → FIXED
Attached file Greasemonkey script (deleted) — 
Thanks! All 516 affected bugs updated.

For completeness, here's the script I used. In the end I used it in a semi-automatic fashion, having to click "Next" for each bug, checking the changes made for each one individually. I ended up doing that because the variations of form found in each bug varied sufficiently that writing a fully automatic script seemed difficult.

In the end I had to fix up these bugs by hand:

https://bugzilla.mozilla.org/buglist.cgi?bug_id=935566,935992,1173716,1266172,1291193,1300075,1330826,1331390,1340962,1363575
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: