Compatibility/Meetings/2023-04-11

• Web Compatibility Meeting Meeting - 2023-04-11
• Minutes: Previous 2023-03-28

Minutes

• Scribe: Dennis
• Chair: Honza

Next State of WebCompat Report (Honza)

• Top 20 - Interop 2023 focus areas
• Risks - Platform analysis (Bocoup and Safari Release Notes - overlap?)
• Trends - Firefox not supported analysis

• Honza: I've been originally considering skipping. The platform teams know what to focus on based on Interop 2023. But given how much analysis we have done, and how many documents we have written, it might make sense to create a new report.
• Honza: For example our "unsupported" analsysis, which got good feedback from Joe already.
• Honza: I think we could provide a summary of Interop 2023 in the "Top 20" section. There are tracking issues, a spreadsheet, and lots of other resources, and we could provide a good summary for the rest of the organization.
• Honza: For risks, they're tied to the Platform Gap analysis, which we have done some work on. There's a meeting about the Bocoup work later today. Simon and Tom were working on identifying potential problems. We have good results there, and if we compile those results, we could have good contents for the risks section. Would also be good to learn if there is overlap between our analysis and Bocoups work.
• Honza: For trends, we have a nice document summarizing the increase of type-unsupported issues. We could create a summary of that document, and use that for the trends section. There might be more trends, Raul and Calin have been working on social sites, and it could be interesting to put that into the trends section as well. I have been pinged by a UX researcher, and they have a list of sites were people were complaining about.
• Honza: I think we have enough content to put something together, so we could build a report for Q1.
• James: I think it makes a lot of sense to have a summary of all the documents in a single document, especially since some of the documents are long. We probalby shouldn't call the "Top 20" that way, and instead explain the current situation of the WCKB, and explain that the focus is currently on Interop 2023, and link to resources to that. I don't think we need to force that into a "this is the top 20 list of WebCompat issues" format, we can just call that "Platform Focus Areas", or directly "Interop 2023".
• Dennis: +1.
• Honza: I'll prepare a template, so we can fill it together.

New round of Peer Diagnoses (Honza)

• Using DevTools to improve Firefox web compatibility (dianosing and fixing issues)

• Honza: I good feedback about that. To summarize: this was an effort where a devtools team member and a webcompat team member had a 1:1 meeting to diagnose an issue together. For devtools, this was useful to identify how devtools are used, and if there is any possible improvement. The devtools team enjoyed that, and it was a good learning experience.
• Honza: The strategy is still focussing on how to help web developers test their pages in Firefox, identify potential WebCompat issues, and fix them. We know that a lot of devs are using Chrome, but we need to provide good tooling for devs to make their pages compatible.
• Honza: Those peer diagnosis sessions were useful as a learning experience. I'm considering doing that again. I can schedule the meetings.
• Dennis: That was useful, happy to do it again. We identified some issues in those sessions, and some of those were fixed already.
• Tom: +1 to Dennis.

Google offline feature, next steps (Honza)

• Look into the UI issues in offline gmail and see whether investing couple of weeks would make a difference.

• Honza: There was good testing and analysis being done here. I think we should not drop the ball here. We know it's a bit more complex, because there's two different offline features, one for GMail, and one for Google Drive/Docs.
• Honza: Apparently there's also an extension that's required for this to work reliably, even in Chrome. Figuring out all those details is going to be hard.
• Honza: However, for GMail, there is no extension required in Chrome, but when we tested a UA spoof in Firefox, we saw some problems, like missing/invisible UI elements. However, it's not *that* broken, so it would be intersting to see if there is something we could quickly fix.
• Honza: Investing a bit of time, a couple of weeks, would be worth it. Maybe there's something that we can fix quickly to get it working better. Identifying what's broken, and checking if it can be fixed.
• James: Who is "we" in this case? Specifically for fixing it, could we ship intereventions? Could we push for changes to platform features? It might be more feasible if we can change platform stuff, but we can't do that ourselves. So maybe the result of this is just a bunch of bugzilla/jira issues to track the technical blockers. If those are fixed, we could push Google to properly enable it in Firefox. I wouldn't expect us to be able to just ship an intervention.
• Tom: Do we know what other things we bring into the UI besides offline mode? Historically, on Google properties, if we spoof as Chrome, Google pulls in a buch of Chrome-specific features that rely on Chrome-specific APIs that we can't even support.
• James: I think the point of this investigation would be "is this broken because of stuff inside Firefox that's broken, or is it broken because Google is going Chrome-only stuff?" - i.e. figuring out how much of the breakage is specific to offline mode, or how much is just broken because we spoof as Chrome.
• Honza: Let's investigate a bit, and if we know more, we can initiate more conversations.
• James: It would be interesting to know if there are technical reasons behind this or not, for sure, and we should make sure the right people are aware of that analysis.

Bocoup reports (Simon)

• Simon: We received a bunch of documents a couple of weeks ago. Have y'all looked at it, and do you have feedback?
• James: I don't think I've seen it.
• Honza: It wasn't shared with everyone, I think.
• Simon: (has shared a copy)
• Simon: Our Safari Platform Gap analysis was based on a similar methodology. These input sources seem to be a good input for estimating web developer interest, and estimating the likelyhood of the chance for a page to break by not supporting the feature.
• James: Some of the top things make sense and match our experience. Other points are a bit more surprising. Other things, like the PiP API, might not apply because we decided against that.
• Simon: The features we looked at were based on Mozilla suggestions and based on caniuse. It's sometimes hard to estimate Safari features, because they don't have the same telemetry basis as Chrome.
• James: I have some questions, like the `rel` attribute for `form`. There isn't a dedicated MDN page for the `rel` attribute, so we count everyone who reads up on creating a form. Maybe the HTTP Archive data would be more reliable, but since we're adding together points from different sources, that might be a concern.
• Tom: There are a couple of caveats in the Appendix, so that data probably has a bunch of gotchas, and it might change if we base it on actual Telemetry data.
• James: For `zoom` for example, we know that it is widely used as some IE-workaround. We also know that it sometimes causes breakage, but it frequently doesn't. The doc estimates that only 6% of zoom usages causes trouble, and that seems reasonable. That might not be reflected in the MDN statistics.
• James: Maybe if we see that >50% of a score are just based on one signal, that might be overrepresented. Eye-balling the graph, that might not be the case right now, but looking out for that might be interesting.