From MozillaWiki
Jump to: navigation, search


Scribed by Dennis

Hello Calin!


Issues where preferences from the browser are changed (SV)

Raul: We have seen:, where a preference was changed from `about:config`,`extensions.InstallTrigger.enabled` set to TRUE. By default it is set to FALSE. The issue reproduces with the default setting (FALSE), works as expected with the setting altered (TRUE). Because this is related to a preference of the browser (and shows a possible fix), should we continue to move future similar issues as valid webcompat issues in our repository, or should we report them on Bugzilla?

Dennis: We usually don't care about pref flips, yeah. But here, a Mozilla Employee reported that issue for us to reach out, so it's a valid issue in this case.

James: Also, the pref is actually the default in Nightly, and while it doesn't yet affect Release, we need to know about those kinds of issues before we ship it to release.

Tom: A good way to handle this is to let the team know. If a weird pref comes up, chances are high that we have to pay attention to it. There are a lot of things only shipped to Nightly, and we need those reports to check when we can ship it to release. In this case, we want to ship interventions and contact the sites before we remove `installTrigger` in release.

Oana: So we should continue testing those, and moving to needsdiagnosis when it reproduces?

Tom: Yeah! And if there is something we need or we don't need, we'll let you know.

James: That only applies to default configs in Nightly, though. If a user flips a random pref, we don't care too much about.

Tom: It might be worth just logging the fact that a pref has been flipped and causes issues. There's some things we don't care about, like privacy.resistFingerprinting, but for other things, knowing it might be good.

Raul: For changed settings, should we create a Bugzilla issue?

Tom: Yeah. Even if the issue is ignored for a long time, having that issue on file is still good.

AllHands + Workweek (Honza)


Some meetings we had notes, recorded talks:

  • WebCompat Tooling for Diagnoses
  • State of WebCompat Report
  • Platform Data Glue & HTTP Archive (with bgrins)
  • Strategy (DevTools + WebCompat + BiDi)
  • Meetings with: Necko, Layout, Accessibility teams

Please, fill out the All-Hands Post-Event Survey


Date & Location: Nov 28 - Dec 2, Berlin

  • Monday - Travel Day, meet at the office
  • Tuesday - Kick-off, year 2022, strategy, roadmap 2023
  • Wednesday - presentations (DevTools, WebCompat, BiDi), team dinner
  • Thursday - WebDriver BiDi meeting at Google Berlin office, peer diagnoses
  • Friday - Wrap up + Travel Day

[beta] State of WebCompat Report (Honza)

Meeting notes from AllHands

Beta version of the report

The following should be done for the beta report. Let's find an owner for each item.

Top 10

  • TODO for everyone: Self assign to ~6 add kb entry issues
  • TODO for Ksenia: Remove fixed issues from KB (or mark them as fixed or move to a subdir)
  • TODO for James: Generate top 10 issues from KB
  • TODO (we already have links, so no direct owner): Add link to related bugzilla bug for each
  • TODO: Provide good context, so readers understand what's every issue about

James: If we're moving entries that have been fixed, the entry should say in which version it was fixed so that we know if ESR is still affected.

James: For the top 10, we can talk about this on Slack. Dumping the top 20 into a Slack thread, and then figuring out which ones of this should be on the final top 10 list.

James: For adding the link, we could add a feature to the tooling to generate a link. But we can also just add it manually.

Ksenia: Do we want to add screenshots for entries?

Tom: I think we wanted to add screenshots for entries where it makes sense.

James: I think the decision was to add things we already have, but not record new things. We also have to figure out how this would work inside a Google Doc.

Tom: We were debating if we want to embed that or link it, but we prefered having it inside the document for the people who just want to skim the document.

(Everyone nods in agreement with Tom)


  • TODO: Include more data sources
    • Relevant things from the last report - CSS Container Queries - 2022 H2 OKR, behind a pref, important to complete and enable in H2
    • Interop 2022 - Pick on things where we haven't made good progress or maybe things that are still in progress and not completed from some reason. Are there any tests that are failing in Firefox but passing in Safari and even in Chrome? Those are risks. Add link to those tests.
    • Interop 2023 - Summarize what this effort is about. We are in "gathering proposals" phase and waiting for the platform. When this is done (end of October) we'll have more details (i.e. in the next report)
  • TODO: The next version of the report can include:
    • Intent-to-ship mailing lists - We should have more experience with "Platform data glue" (at the time of the next report) and this might be the one new analyzed data source.

Tom: With Ksenia and I being the leads on the risks section, we're going to pick two specific topics we're aware of, and create some sort of process that we can use in the future to asses risks, even before we try to find more datasources.

James: We're probably not making a lot of progress there if we're supposed to create the beta report in the next week. For the interop 2022 stuff, I should have a discussion with people to see if we should include it in this report or not, as most things could be resolved when the report is done. For interop 2023, the report probably says that there currently isn't anything, but a few areas might be concerning in the future. So some points might be placeholders to be filled in a future version of the report.

Tom: So for the next report (or the next two), the risks sections is probably more of a slim version, and will have more content in the future.

Honza: I think we should have something by Tuesday next week. You said you want to pick two topics, do you think there is enough time to do that this week?

Tom: For now, it might be worth focussing on the other parts of the report, but Ksenia and I will look into possible topics and get the work on the risks section started.

James: I can write the Interop part of that. The reason there is nothing for Interop 2023 yet is that we have no positions on the proposal. Risks could be things that other vendors want to include, but we don't. By the time of the final report, we know what's happening. There might be nothing if all our priorities are aligned, but if not, we'll know that by the end of November. I can write something up for this version, and we can update it for the next version.

Tom: Okay, then Ksenia and I will be working on extracting things from the platform data glue, and we can focus more on the Interop side for the next version.


  • TODO: Add stats about unsupported web compat reports. Try to split it by country/domain
  • TODO: Come up (or use an existing) labels for stats. Could we do it for performance?
  • TODO: What we can dig from collected performance?

Honza: What new stats are realistic to get done this week?

Ksenia: I will try to group the existing "unsupported" data by country to see if there's anything interesting there.

Honza: What about coming up with new/different labels?

Dennis: We should be looking at the existing labels and whether we can group them or add new ones, but we don't have time to do it this week. I think the performance label is well maintained, so we could use that if it's interesting. I will look into the performance label(s)


  • TODO for James: explain our scoring logic (for top 10)
  • TODO: explain our methodology and thinking when processing and interpreting data from various data sources

James: I'll write a summary of how our scoring works. I think it's worth explaining since it shows there is a method behind it.

James: Where should all the writing work happen? Is there already a document for it?

Honza: There is, I added it to the agenda below the headline! Let's put everything we do there. It's a copy of the old report, so feel free to delete all the old information.

Dennis: We should set a deadline for adding new entries, because adding new entries is pretty much blocking all other work.

Honza: We should have a report done by Tuesday next week, for the meeting.

James: I suggest having the entries done by Thursday. That gives us Friday to discuss it and have it written up by Monday. For the other sections, those aren't blocked by the entries itself, so we can just start writing them now.