Compatibility/Meetings/2023-05-23

• Web Compatibility Meeting Meeting - 2023-05-23
• Minutes: Previous 2023-05-16

Minutes

• Scribe: James
• Chair: Dennis

Identifying pages not supporting Firefox (Honza)

• How technically feasible is this?
• Could we build a prototype?
• What data do we need to collect from every page to classify it?

Notes:

• Honza: Want to classify pages into those that do and don't block Firefox. Would give us big picture data. We have reports which suggest it's a trend, but having a system to collect data on a large number of pages would help us assess the impact. People understand this is a concern. Not clear how easy it is to do the classification. We have some known broken sites we can use. What do we want to use as the input data?
• Tom: Possibly feasible, but maybe hard to make it work well. The text might be in the source, but not displayed. So need to use visible text. Check for mentions of Chrome / Chromium / etc. Could be other browsers being blocked. I've worked on automated comparison of rendering vs Chrome. We could do something similar here; look for a big difference. Might be more involved.
• Dennis: A big concern about this is that a lot of pages do the blocking via JS, so you'd need to execute JS.
• James: I think Disconnect is using Selenium, so in theory, that works. That's also true for WebPageTest, but it would be an issue if we want to use HttpArchive data. There are two options for classification: we could come up with a bunch of manual classifiers, like "there is a link to a Chrome download". The other approach is to build a ML model based on existing reports we already have. As Tom said, one option is to just extract all the visible text and throw that into a ML model. We could use a difference between Chrome and Firefox, either text or image. But we can create a list of "known blocking" and "known working" sites and validate a model.
• Ksenia: We could try to build it with BugBug and see how it goes.
• Tom: It's worth noting that we need to be careful because some websites might not present this prompt on the home page, so we'd miss some sites.
• Honza: Do we know the ratio?
• Tom: No. It might depend on the type of the app e.g. WebRTC.
• James: We definitely see some cases where everything works fine until you try to log in or something. Bug it's still worth a try, we know which sites we know are unsupported, and we can compare that with the result of the model, and gauge how much we're missing.
• Tom: I think we should try it and see what we get.
• Ksenia: Build a script based on Selenium that would go to all the URLs in WebBugs and use that to build a model?
• Honza: Sounds promising. Who wants to own it?
• Ksenia: I'd like to try, but I don't know how high the priority is.
• Honza: It's similar priority to the KB work, we can reshuffle existing work. Start with a short document that summarises the approach and we can share that internally and get feedback.

Web Compat KB (Dennis)

• Update
• Anna confirmed, we are going to use BigQuery

Notes:

• Dennis: It is correct that delete/update statements will rewrite the table, but we're expecting the total amount of data to be small enough that this doesn't matter. Our general tooling around BigQuery is better.
• Honza: Other questions now that's resolved?
• Dennis: DB schema we designed doesn't make sense for BQ, and the existing tools we have will need to be updated. Query language is a bit different. My plan is to set up a GCP project as soon as possible. Ksenia will create a script to start importing existing data.
• James: We have a bug component, should we start using it?
• Dennis: Yes, but we haven't decided how to do it. We should add existing entries. We need to split the work.
• James: Could we do it doing triage / diagnosis and then lazily add the existing KB entries?
• Dennis: During triage seems hard because creating a bug takes time. But during diagnosis makes sense. If we identify the issue during the meeting we should create a todo list.
• Tom: We had a "needs-kb-entry" flag.
• Dennis: We have it on web-bugs, we don't have that on bugzilla. We could invent a whiteboard flag.
• Tom: We could also use webcompat-priority.
• James: I hope that, at least in some cases, we can do things sync during the triage meeting. So the goal would be to make the process fast enough to be able to do it in the meeting, as opposed to adding it to a queue and do it later (which might not happen soon, given that our queues are already full). At least filing a bug for something that we already know might be fast enough.
• Dennis: We can try.
• Tom: Doing it just after the meeting might work if we reserve that time.
• Dennis: Our queues are already pretty full and then there are other meetings, so we could try doing it sync and see how it goes.
• Tom: We could add another timeslot on weeks where we need extra time.
• Honza: What needs to be done apart from file a bug?
• Dennis: We need to file a bug and add the URL to the user story. Could be quick, but filing a good issue takes more time. Just making a skeleton issue is fast, and more complex cases are likely to require diagnosis anyway.
• Honza: One bug per confirmed issue?
• Dennis: Yes. In some cases we can do this during triage. e.g. WebUSB support missing.
• James: It's not one bug per issue. It's one bug per group of issue. Even if we don't have a full diagnosis, like "unsupported sites".
• Honza: Let's try and see how it goes. What about converting the existing KB entries? Is that manual work?
• Dennis: Mostly manual work because there's not quite enough data to create a script. But it's too much for one person to just do it.
• Honza: Should we write a little process doc so everyone can follow?
• Dennis: We can; we might not need one. Need to make sure it's split evenly.
• Ksenia: A lot of existing issues are already fixed.
• Dennis: Maybe we should import those anyway, to record the progress.
• Honza: I'll split it up and assign everyone a list.
• James: What's the tradeoff of writing a script?
• Dennis: Maybe not worthwhile given the initial time to create it. But maybe it's OK.
• Ksenia: It might be worth investigating; I can look into it.