Sometimes, a website is broken with a webcompat issue. In the best case, the webcompat team is able to diagnose it. (You can help). The team has been keeping a regular pace for diagnosis for the last year.

But after diagnosis what should we do?

There are a couple of possibilities:

• Outreach: After finding a point of contact for the website, the webcompat team (or a contributor, you can help again) sends a message explaining the issue and asking for help to get it fixed. It's time consuming and often people on the other side, even if they have an intent to fix the issue, do not reply. Sometimes they never reply.
• Fixing Gecko: Sometimes Gecko is really broken OR implements the right thing, but the broken behavior of Blink or WebKit so popular that Mozilla has to implement the broken behavior.
• Site Interventions: These are patches which modify the website on the fly and fix the issue before the site is actually fixing it. If the site is never fixed, at least the normal users will get a better experience. Let's talk about these.

Site Interventions

We follow a strict release process tied to the release cycle of Firefox. You can discover our CSS interventions and JavaScript Interventions. The calendar for the upcoming releases is defined in advance.

Before each release cycle for site interventions, the Softvision Webcompat team (Oana and Cipri) makes sure to test the site without the patch to discover if the site intervention is still necessary. This takes time and requires a lot of manual work. Time that could be used for more introspective work.

To activate deactivate site interventions, you can play with extensions.webcompat.perform_injections in about:config.

Automated Testing Of Site Interventions

So we started to discuss again the prospect of automating the site interventions patches verification. We often discussed about it, but we often wanted it to be too perfect. Opera Software had for browser.js a very neat system. Each time a patch was not valid anymore it was sending an alert telling us that we should fix or remove it.

We should probably target something simpler by using webdriver at least for the simple bugs. By the way you should read Improving Cross-Browser Testing, Part 1: Web Application Testing Today if you want to know a bit more about the landscape of testing in browsers these days. We need to make it simple enough so that people who are checking the validity of a patch can create a simple webdriver script replicating the task done by hand. Then we could aim for a very simple solution where someone run the script and see if something is broken. It is still not fully automated but it's a good first step.

Keeping things simple even if a bit hackish at the beginning help other people in your community to grow, to engage in the process, and to evolve from there. It's an opportunity to acquire new skills.

Histography, an example

Histography is working in Firefox, but only if we fake the user agent string (The bug, the patch).

A webdriver script here would be.

1. Go to http://histography.io/
2. Wait for the page to be fully loaded and code executed
3. Check if the text "WE ARE CURRENTLY NOT SUPPORTING YOUR BROWSER" exists in the page
4. If True, we still need the site intervention. If False we can add it to the list of patches to remove for the next release.

The content of the page is

<div id="about">
  <h2>SORRY!span>h2> WE ARE CURRENTLY NOT SUPPORTING YOUR BROWSER <br>(BUT WE WILL SOON) <br>
  <br>
  <br>
  <br>TRY <a href="https://www.google.com/chrome/">CHROMEspan>a> OR <a href="https://www.apple.com/safari/">SAFARIspan>a>
span>div>

In Python that would roughly translate to:

from selenium.webdriver import Firefox
from selenium.webdriver.firefox.options import Options

# Here usually you may define a profile
browser = Firefox()

# The meat of the code
# Go the site
browser.get('http://histography.io/')
# find the element with an id having the value about
el = browser.find_element_by_id('about')
# extract the needed text
message = el.text
# test the message.
assert "NOT SUPPORTING YOUR BROWSER" in message

That would make it a lot easier and more systematic for testing and remove the burden of manually testing every steps for every releases.

Otsukare!

https://www.otsukare.info/2021/01/22/site-interventions-and-webdriver