Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mirror data to eliminate inconsistencies #3869

Closed
2 of 7 tasks
queengooborg opened this issue Apr 12, 2019 · 5 comments
Closed
2 of 7 tasks

Mirror data to eliminate inconsistencies #3869

queengooborg opened this issue Apr 12, 2019 · 5 comments
Labels
bulk_update An update to a mass amount of data, or scripts/linters related to such changes duplicate Duplicate issues or pull requests. This one is closed in favor of the other issue or pull request.

Comments

@queengooborg
Copy link
Contributor

queengooborg commented Apr 12, 2019

Something to help eliminate inconsistency issues is to mirror all the data from the primary browsers over to their mobile counterparts and forked browsers. This is an issue to track a huge series of pull requests that do just that, mirroring Firefox onto Firefox Android, and Chrome onto Chrome Android, Webview, Samsung Internet, and Opera. (Not Opera Android just yet.)

The PRs are as follows:

Another part is checking the primary browsers with their mobile counterparts and derivatives (such as Chrome to Opera, Firefox to Firefox Android) and making sure they roughly match. I went through and ran a script that checks to see if the counterparts/derivatives have values marked as "false" when their inheritance does not (i.e. Chrome has support for feature "foo_bar" but Opera does not). They are all listed here: https://gist.github.com/vinyldarkscratch/55e77caec88a5e67739f4fa80204db53

@queengooborg queengooborg added data:api Compat data for Web APIs. https://developer.mozilla.org/docs/Web/API data:css Compat data for CSS features. https://developer.mozilla.org/docs/Web/CSS data:html Compat data for HTML elements. https://developer.mozilla.org/docs/Web/HTML data:http Compat data for HTTP features. https://developer.mozilla.org/docs/Web/HTTP data:js Compat data for JS/ECMAScript features. https://developer.mozilla.org/docs/Web/JavaScript data:svg Compat data for SVG features. https://developer.mozilla.org/docs/Web/SVG data:webext Compat data for Browser Extensions. https://developer.mozilla.org/Add-ons/WebExtensions data:xpath 🛤️ labels Apr 12, 2019
@queengooborg
Copy link
Contributor Author

@jpmedley Would you say that this is a reasonable method of getting rid of the null and true values that have answers within the desktop versions? (Something to note is that this doesn't replace false values, or existing version numbers, so features that we have determined were disabled in Webview or came to Chrome Android at a later date will not be affected.)

@jpmedley
Copy link
Contributor

I'm worried about the edge cases where desktop and Android didn't ship in the same version. I would only do it with the following rules:

  • Set WebView to false for anything listed in this file.
  • Replace null with true when desktop shows support. Use true even if desktop has a number. I can filter by these later and work to change true to a specific number.
  • Leave alone any places where WebView and Android show true while desktop shows a number.

My actual preference would be to review all your PRs. My problem is I'm on the hook for content related to a Chrome beta release and Google IO which both happen in about two weeks.

@queengooborg
Copy link
Contributor Author

I totally understand what you mean there, thanks for taking the time to reply! Yeah, this doesn't affect any Android versions that were set to anything other than null; only null values are replaced with their desktop mirroring, which covers the first and third rules. I'm willing to bet that all the WebView non-exposed APIs have already been set to false, but I'll be sure to do a double-check and make sure that there weren't any stray values hanging around. 😉

@queengooborg queengooborg added bulk_update An update to a mass amount of data, or scripts/linters related to such changes and removed data:api Compat data for Web APIs. https://developer.mozilla.org/docs/Web/API data:css Compat data for CSS features. https://developer.mozilla.org/docs/Web/CSS data:html Compat data for HTML elements. https://developer.mozilla.org/docs/Web/HTML data:http Compat data for HTTP features. https://developer.mozilla.org/docs/Web/HTTP data:js Compat data for JS/ECMAScript features. https://developer.mozilla.org/docs/Web/JavaScript data:svg Compat data for SVG features. https://developer.mozilla.org/docs/Web/SVG data:webext Compat data for Browser Extensions. https://developer.mozilla.org/Add-ons/WebExtensions data:xpath 🛤️ labels Aug 14, 2019
@queengooborg
Copy link
Contributor Author

As mentioned in @ddbeck's comment, this should follow the bulk update process we have been formalizing recently. So, let's give this a shot after we have completed migration 001, to sort features alphabetically!

@queengooborg
Copy link
Contributor Author

I'm closing this PR in favor of #4719.

@queengooborg queengooborg added the duplicate Duplicate issues or pull requests. This one is closed in favor of the other issue or pull request. label Aug 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bulk_update An update to a mass amount of data, or scripts/linters related to such changes duplicate Duplicate issues or pull requests. This one is closed in favor of the other issue or pull request.
Projects
None yet
Development

No branches or pull requests

2 participants