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

RESOLVED FIXED

RESOLVED FIXED
a year ago
a year ago

Production
---

## Attachments

### (1 attachment)

 5.07 KB, text/plain Details
(Assignee)

### Description

a year ago
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.
(Assignee)

### Comment 1

a year ago
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:

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);
(Assignee)

### Comment 2

a year ago
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):

parity-chrome: 213
parity-opera: 36

compat-edge
parity-edge: 76

parity-ie: 90
parity-ie10: 1
parity-ie11: 1
parity-ie8: 3
parity-ie9: 1

compat-webkit
parity-safari: 31
parity-webkit: 39
(Assignee)

### Comment 3

a year ago
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
(Assignee)

### Comment 4

a year ago
CC'ing everyone who's set a "parity-*" flag in the whiteboard field in the last 2 months.

### Comment 5

a year ago
: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)
(Assignee)

### Comment 6

a year ago
Sounds good to me. I've also sent an email to mozilla.dev.platform to make sure there are no objections.
Flags: needinfo?(jwatt)
(Assignee)

### Comment 7

a year ago
(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.

### Comment 8

a year ago
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?

### Comment 9

a year ago
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
(Assignee)

### Comment 10

a year ago
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.
(Assignee)

### Comment 11

a year ago
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.
(Assignee)

### Comment 12

a year ago
I repeated comment 1 to search across all products and components (not just Core) using:

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:

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-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
(Assignee)

### Comment 13

a year ago
So I propose:

parity-chrome
parity-chrome: 309
chrome-parity: 6

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
(Assignee)

### Comment 14

a year ago
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
(Assignee)

### Comment 15

a year ago
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.
(Assignee)

### Comment 16

a year ago
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)

### Comment 17

a year ago
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)

### Comment 18

a year ago
(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.
(Assignee)

### Comment 19

a year ago
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.

### Comment 20

a year ago
I've deleted that catch-all keyword. Working on the script.
Flags: needinfo?(ehumphries)

### Comment 21

a year ago
Dylan, is this something Israel could help with? I'm not going to have time to finish this before tomorrow.
Flags: needinfo?(dylan)
(Assignee)

### Comment 22

a year ago
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)

### Comment 23

a year ago
:jwatt, here's an example I wrote in nodejs for editing whiteboard tags.
Flags: needinfo?(ehumphries)

### Comment 24

a year ago
I'm not sure I understand the task required here?
Flags: needinfo?(dylan)

### Comment 25

a year ago
(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)

### Updated

a year ago
Assignee: ehumphries → jwatt

### Comment 26

a year ago
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.
(Assignee)

### Comment 27

a year ago
All done. Can you remove me from the 'no-bugspam' users please?
Flags: needinfo?(ehumphries)

### Comment 28

a year ago
Done! Thank you.
Status: NEW → RESOLVED
Last Resolved: a year ago
Flags: needinfo?(ehumphries)
Resolution: --- → FIXED
(Assignee)

### Comment 29

a year ago
Posted file Greasemonkey script
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.