Fix aggregation of privacy features#322
Fix aggregation of privacy features#322wbamberg merged 2 commits intomdn:masterfrom Elchi3:webext-privacy
Conversation
|
Thanks for fixing this. I noticed it yesterday but didn't have time to look into it. It seems that the underlying problem is that we're generating tables with depth 1, but these parts of the tree don't have any compat data at depth 1. So an alternative way to fix it is to remove the special-casing for The side-effect of that is that we then list compat data for subfeatures like @Elchi3, what do you think? [1] on that topic, I wish there was a simple way to say "iterate through all the subfeatures, as deep as you have to". I thought maybe we could have it do if you omit the depth argument, it means that? So depth means, "limit depth to"? |
Yes, I thought about just removing special-casing here and just use a depth of 2. But as that adds a lot other things to the tables on the page I was unsure about it and only wanted to provide a quick fix here.
Yes, likely something we should do. Somewhat out of scope for this hotfix I would say, though. |
Yes, I think this would be better :). |
* mdn/kumascript#321 - Compat: Use footnotes for alternate name * mdn/kumascript#322 - WebExtAllCompatTables: aggregation of privacy features * mdn/kumascript#326 - Compat: Update for BCD v0.0.7
The data got changed in mdn/browser-compat-data#364 and the aggregation doesn't work well with it: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Browser_support_for_JavaScript_APIs#privacy