Get an engineering review

[biancadanforth]

As part of a more rigorous review process for landing shield studies (currently modeled after this), this study should receive an engineering review.

Firefox Engineering has asked that this reviewer be a Firefox Peer.

This is a meta-issue for any engineering-related concerns.

Related issues:

• 72 (P2)

• 73 (P2, closed)

• 75 (P3)

• 88 (P1, closed)

Engineering reviewer: rhelmer

[biancadanforth]

Testing the study on the Try server

With @rhelmer's help, I was able to test this shield study on the try server (Nightly only).

First attempt: Cancelled in Nightly/Central branch

The first test ran the study as-is, but we discovered that was not going to work and the build was cancelled due to:

• We need to ensure one of the two experimental branches ("fast" or "private" i.e. worst case scenarios) are what are tested, particularly for performance.
• Test infrastructure prohibits outbound connections (e.g. end-of-study surveys), as those can prevent perf tests from being repeatable and can be exploitable.

Second attempt: Success in Nightly/Central branch

Addon Configuration The addon was run through the try server configured to:

• Force the "fast" experimental treatment branch
• Not have any external survey endpoints Note: The addon was patched into Firefox as a System Addon. I document this process in PR #12 .

What tests were run ./mach try -p linux64,win64,macosx64 -u all -t all --artifact This runs all unit tests and perf (TALOS) tests on all desktop platforms.

Results

The results of the test can be found in Treeherder.

Performance Tests Results of our patch compared to mozilla-central (Nightly)

• sessionrestore tests
  • These look at how long session restore took; it took longer with this patch than without.
  • We expect some regression to sessionrestore, since we are re-implementing Tracking Protection, and our implementation is not as optimized.
  • It’s possible that resolving Issue #73 could improve this, but rhelmer wouldn’t expect a big change.
• ts_paint tests
  • This measures time to first draw from the graphics library. If the addon is starting up too early, it might be slowing this down.
  • It’s possible that resolving Issue #73 could improve this.
• Responsiveness tests
  • We’re not really sure what this measures and why it has regressed.
  • Recommendation: Ask Joel Maher.

Non-Performance Tests

• Memory leakage
  • There were a lot of orange (failed tests) citing errors related to “leaked X windows” (Example).
  • Recommendation: Make sure addEventListener and removeEventListener code point to the same reference. It looks like the bind method creates a new function reference each time it is called.

Note: Any tests of interest that failed in the try push can be run individually on my local machine without having to spin up cycles on the try server. Ex: ./mach test browser/components/sessionstore/test/browser_394759_behavior.js for MochiTests.

Next steps

Follow up tests in Nightly

• [x] Try running a failed test that cites leaked windows locally to see if the result is reproducible with/without the addon. If the addon seems to be the cause, try updating the binding references and perform the same test locally.
• [x] Try listening for sessionstore-windows-restored instead of browser-delayed-startup-finished observer for adding the Feature in bootstrap.js to see if TALOS results are improved (Issue #73).

Understand Responsiveness (Performance) Tests

• [x] These tests are not well understood, and we should ask someone like Joel Maher about what the regressions could signify, and what, if any, action should be taken.

Test on the Release branch Since this study will be for Firefox release, we attempted to run the same set of tests in the Release branch as in Nightly above, again using artifact builds. Unfortunately, the build steps for each test would fail before even getting to the test itself, so the tests were cancelled.

• [ ] Follow up with #build in IRC on how we can run these tests in Release.

NOTE: rhelmer recommends testing in Nightly and locally with artifact builds as much as possible first, since that is faster/more cost-effective.

[biancadanforth]

Update for Next Step: Understand Responsiveness (Performance) Tests

I spoke with jmaher, here’s what he said:

On what Responsiveness tests measure

• These tests measures responsiveness by measuring the time it takes for the browser to respond when a page is visited and refreshed c. 25 times from a page set of 50 top websites. This is driven by an addon.
• In general, responsiveness is a measure of startup time before the user can do something in the browser (like view a page). The idea is that the tests keep triggering events into the Event Loop; they have an expectation for how long they needs to wait to get a response, and know when that time is exceeded.

On whether our result is an outlier

• No. Joel re-ran a number of the “responsiveness” tests from Treeherder to find that the test results showed a consistent regression around 10%.

On whether the result is significant

• It’s definitely above the average which hovers around 2s, but a 10% regression means it slows down responsiveness (in this case, browser startup time) by about 150-200ms.
• For perspective, most addons also show red (significant regressions) in Perfherder as this one does for these exact same tests ("Responsiveness", "tspaint", "sessionrestore"). Some addons in the past have shown as high as 20% regressions, and historically, system addons teams in Firefox spend months bringing that down to 5-6%.
• If this were a fully-fledge feature in Firefox, a 10% regression would be too high, but he's not sure for a Shield study. If we do find a way to bring it down, he'd like to know how we did it.

@rhelmer, what do you think we should do now that we know what this test measures and the extent of the regression? My thinking is that this regression is largely due to an inefficient re-implementation of Tracking Protection. We might be able to reduce the extent of regression by memoizing blocked third parties in WebRequest.onBeforeRequest, but I'm not sure how big a dent that will make, and if that is worth doing given our other priorities.

[rhelmer]

@rhelmer, what do you think we should do now that we know what this test measures and the extent of the regression? My thinking is that this regression is largely due to an inefficient re-implementation of Tracking Protection. We might be able to reduce the extent of regression by memoizing blocked third parties in WebRequest.onBeforeRequest, but I'm not sure how big a dent that will make, and if that is worth doing given our other priorities.

Yes I agree... the important thing is to note the regressions and what we believe is causing them. It seems unrealistic to expect 0 regressions when this is implemented as an add-on vs. as a built-in feature.

[biancadanforth]

Update for Next Step: Follow Up Tests in Nightly

Performance regressions on tspaint, sessionrestore and responsiveness

• This patch seems to have removed any certain, significant performance regressions.
  • Here's the Perfherder results for the first test described here that I am trying to improve. And here are the Perfherder results from this patch.

Non-Performance "leaked X windows" unit test failures

This patch and this patch were intended to try to address the memory leakage errors from many of the unit tests. Unfortunately, the Treeherder results for unit tests did not improve, so I decided to ask _6a68 (jhirsch) per rhelmer's suggestion. Here's what he suggested:

• The errors of the form “LOG ERROR | TEST-UNEXPECTED-FAIL | devtools/client/netmonitor/test/browser_net_prefs-reload.js | leaked 13 window(s) until shutdown [url = about:blank]” are probably referring to window object references (including listeners and references to the objects themselves) that aren’t completely removed when the addon shuts down.
• If you look at many of these “leaked X windows” tests, a lot of them are associated with existing “Intermittent” failures with bugs in Bugzilla. It can be hard to tell if your failure is due to a known intermittency, but you can look through those bugs and also just simply rerun the test several times to get a sense of repeatability. You can also look up the test in DXR and "blame" to find out who most recently patched the bug and ask them questions about it.

• Normally, with failed tests, when you select a particular test, a panel will open at the bottom with a “Failure Classification” tab focused. You can click the [...log] link next to the error message. This log will show you the stack trace of the error, so you can see where in the test it failed. If you don’t see anything right around that error in the test that is related to the error, it might be that you violated a previous test’s post-condition that may not have been checked by this test. This is the case for the “leaked X windows” errors.

_6a68's recommendations:

• Explicitly set all ChromeWindow (and descendant DOM/window elements tied to it/them) to null on shutdown. Using either a:
  • WindowManager pattern
  • [Example 1](https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIWindowMediator#addListener())
  • Example 2: Thanks to _6a68
    • When I had to do window iteration stuff for universal search, I used mardak's WindowWatcher script: https://github.com/Mardak/restartless/blob/watchWindows/bootstrap.js
    • And I used it to register load and unload handlers for each window: https://github.com/mozilla/universal-search/blob/fb3ae049d290f56ea7f3ab7a857273376d9232d8/lib/universal-search.js#L54
    • One thing I noticed in my old code that I didn't emphasize when we talked: not only do you want to free any window references in your code, but you also want to delete all of your code off of the window when it's closing. I do that here https://github.com/mozilla/universal-search/blob/fb3ae049d290f56ea7f3ab7a857273376d9232d8/lib/universal-search.js#L101
    • In this case, universalSearch is a global that I used to hold all the libraries I loaded into the window. I Cu.import everything onto that win.universalSearch global https://github.com/mozilla/universal-search/blob/fb3ae049d290f56ea7f3ab7a857273376d9232d8/lib/universal-search.js#L175. Just make sure never to unload Firefox JSMs like Console.jsm; that’s a global unload for all of Firefox!
  • Adding an “beforeunload” event listener to each window, you should dereference the window and remove listeners. The “unload” event occurs just as its unloading and is too late. Generally using “beforeunload” is not a good pattern in web development because it can block the window from closing, but in this case, it’s fine.
• Finally, once these changes are made, run all unit tests but this time, only on Linux64. This is because the number of MacOS machines in the test farm are pretty limited, and the failure you’re addressing (“leaked X windows”) should be platform-independent (with the exception of the Hidden Window which likely only exists in Macs, but you’re not really doing anything with it in your addon except to check if it’s there).

[biancadanforth]

Update for Next Step: Test in Release

Issue #88 is attempting to fix the window leak errors from Try server unit tests, which are unfortunately a blocker for shipping this study.

I did manage to run the exact same set of tests against the exact same patch in the release branch of Firefox (up to this point these tests had been my patch against mozilla-central, aka Nightly). Here's the process for doing that for posterity.

Here are the Treeherder results for my patch (as of this commit in PR #89 ) in mozilla-central. 45 failed unit tests.

Here are the Treeherder results for my patch (same as above) in release. 43 failed unit tests.

The good news:

• the test results are very similar between mozilla-central and release
• With mconley's help, I've fixed several leaks and am now passing 10 more unit tests (with PR #89 compared to the current master branch, Treeherder).

The bad news:

• I'm still failing 40-something unit tests.

[biancadanforth]

Update: All memory leaks fixed with PR #89. Let's hope it stays that way. Here are the Treeherder results against release for that patch, compared to before. See #92 for the kinds of fixes that led to 0 failed tests for "leaked X windows".

Next step: What are these other 22 non-memory leak unit tests that are failing? Do we need to be concerned about them?

[biancadanforth]

Update on Next Step: What are these other 22 non-memory leak unit tests that are failing?

Note: the alphanumeric designation for each test varies each Try run for each build of Firefox (ex: Linux64 opt versus Linux64 debug, etc.), so the same test could have a different number (e.g. bc4 versus bc10) for two different builds. Some of the same tests are failing across builds. This list reflects all the unique tests that are failing.

UNEXPECTED FAILURES

• c1: test_headless_screenshot.html
• bc2: browser_pluginnotification.js
  • This is a notification for enabling flash on a website.
  • This is a problem, because if the notification isn’t showing properly, it can break a website that uses flash.
  • I tried this test locally with and without the patch, and the patch seems to be causing the failure (it fails in 3 places).

EXPECTED FAILURES

• bc4: browser_all_files_referenced.js
  • The unreferenced files from this error never get loaded because they are associated with the intro panel or pageAction panel, which never show during this test.
• bc7: browser_PageActions.js
  • This checks against a static list of pageActions; since this study is not a permanent addition, this list has not been changed and that’s why it’s throwing an error when it sees the study’s pageAction button.
• bc8: browser/extensions/tracking-protection-messaging-study/test/browser/browser_tracking_protection_study_ui_check.js
  • This is a stub of a test rhelmer wrote that I just kept in here to add the ability to run our own unit tests in Firefox. It just hasn’t been updated.
• l10n:
  • It is trying to load a file at http://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-58.0.3.en-US.linux-x86_64.tar.bz2, which is located in mozilla-central, not in release.
  • This is likely a problem with the fact that these tests were performed with an artifact build of Release.
• enUS: /builds/worker/workspace/build/src/layout/base/nsAutoLayoutPhase.cpp
  • This error is from something in the C++ code. This is a part of the build I downloaded. My study doesn’t touch C++ code. This problem may go away with a full build.
• x6: test_ext_startup_cache.js
  • WebExtension error. There is an open bug for intermittent failure with this error code. I ran the test again and it is passing now after failing the first time.
• 5: test_ext_webrequest_basic.html
  • WebExtension error. There is an open bug for intermittent failure with this error code. I ran the test again and it is passing now after failing the first time.

Next steps

1. Run a full (i.e. non-artifact) build against the release channel for this patch to see what test failures can be attributed to the fact that we were testing an artifact build.
2. Reach out to myk@ to ask about the C1 test.
3. Bisect the study to find why the bc2 test is failing. Failing that, ask dothayer@ or fgomes@.

[biancadanforth]

Update: Next step - Run a full (i.e. non-artifact) build on the try server against the release channel for this patch.

Full build Treeherder versus Artifact build Treeherder for changes including PR #89 .

I learned that my local build of Firefox saves changes I make in its own user profile, so when I had previously toggled Tracking Protection to be on "always", that affected subsequent ./mach builds and possibly Try testing. I have therefore re-run the original artifact build tests (the artifact link above in this comment). More specifically: there is a temporary profile used for ./mach run that is cleared out every time you ./mach clobber. ./mach run creates a new profile if it does not exist, and it goes into ./${OBJDIR}/tmp/scratch_user/. Local testing and try server testing use a new profile each time.

Comparison: Both builds had all the same bc test failures listed in the previous comment.

L10N:

• Same failure still occurs in full build of patch as in artifact build of patch.

X6:

• Passed this time for both full and artifact build. Confirms this is an intermittent failure likely not due to my patch.

5:

• Passed this time for both full and artifact build. Confirms this is an intermittent failure likely not due to my patch.

enUS:

• Passed this time for both full and artifact build. Confirms this is an intermittent failure likely not due to my patch.

[biancadanforth]

Update: Next step - Reach out to myk@ to ask about the C1 test.

Test summary per myk@

This test opens headless Firefox. As soon as Firefox is ready to browse to a page and as soon as the page is loaded, it takes a picture of the page and then immediately closes Firefox.

Whereas most tests start with a single window in Firefox (with a head!) open to about:blank, this test actually starts up Firefox in headless mode itself.

myk@'s thoughts on what could be causing the test to time out

Headless screenshots as a feature have historically seen quite a lot of race conditions on startup, as Firefox is not designed to start up and quit very quickly. We actually delay some startup functionality so we can show a page to the user as quickly as possible. Parts of Firefox’s initialization may fail because it doesn’t expect Firefox to quit so soon on startup.

My hypothesis is that there are async calls in your bootstrap.js startup method that haven't returned before the test finishes and closes Firefox.

An alternative hypothesis is: Is Firefox quitting at all? Is something blocking it from closing, because it's still in the process of being initialized? Or if there's something that's holding open a file in that Profile directory at the time Firefox quits?

My guess is that there is async telemetry running or some async setup aspect to the study itself that may not have returned when headless Firefox is closing.

One thing you could try is to disable Shield studies when in headless mode to see if the test passes. If this is controlled by a pref, then you could add that pref to the profile the test uses. Mochitest creates its own profile for these unit tests; but that may be too upstream, since it will affect all other tests. You could edit the copy pulled from mochitest by editing this test directly at or before this line. Read the mochitest file using OS.file, add a pref to it and write it back out to the new location.

Conclusion

There's already an intermittent bug failure for this test. Myk ran your patch locally several times and couldn't get the failure to reproduce. Myk also noticed this failure only occurs in my patch on opt builds, not on debug builds, which makes it much harder to track down.

The other test failure in this group about message counts is a totally different test that was grouped together. I tested this one locally for your patch, and it is passing repeatedly. So this is another intermittent bug.

After talking with rhelmer about this test, we agree it could be a bug in ShieldUtils.jsm, but since the test was intermittent against the same patch, it could also be a bug in the test itself. The risk here is that if a user is using Firefox in headless mode and taking screenshots where Firefox is only open for fractions of a second at a time while enrolled in this study, the study may not properly shut down.

What we're going to do about it

• Don't deploy Shield studies to profiles in headless mode from Normandy
  • We probably just don't want to deploy Shield studies to profiles running in headless mode. Mythmon said currently Normandy doesn't check for headless, but probably should. Rhelmer filed a bug to add this check upstream.
  • While I could add a check for headless mode as an eligibility criterion to the study, that would cause the study to end/try to uninstall itself when other headless Firefox tests are run. So we probably don't want to do that. If, in future, we decide that we do, here's an example of how to detect headless mode.
• I did check that the headless screenshots feature /Applications/FirefoxNightly.app/Contents/MacOS/firefox-bin -headless -screenshot https://developer.mozilla.com works with and without my study installed (with an experimental branch running).
• See if it happens again for another Shield study
  • Since this is the first Shield study run through this test, and the test failure is intermittent for this patch, we will not give it too much stock for now and consider digging deeper if we see the failure again for another study in future.

[biancadanforth]

Update - Next Step: Bisect the study to find why the bc2 test (browser/base/content/test/plugins/browser_pluginnotification.js) is failing. Failing that, ask dothayer@ or fgomes@.

TL;DR: The test first starts failing (intermittently) at this line when I add the WebRequest.onBeforeRequest listener. Since the failure is intermittent and the feature works with the addon installed under "normal" conditions, @rhelmer does not see this as a blocker. See below for a more detailed explanation.

---

I bisected the code and find where my code starts to fail in PR #94 . Go there for more details.

I talked with dothayer@, and he suspects the problem is a race condition. To show the flash plugin notification, there must be a "plugin binding attached" event. Currently the logic in this test trusts that this event will fire before the content task (the line just before the failure) returns, but it's not a given. It's possible that with an onBeforeRequest listener, this event (which may require that the request for flash comes through) is not always firing before that content task returns.

He suggested I try adding the line:

await new Promise(resolve => executeSoon(resolve));

just after the content task above to try to process any events in the queue before attempting to get the notification element. Unfortunately, I was still seeing intermittent failures -- i.e. the "plugin binding attach" event has not always taken place before the content task returns.

After speaking with rhelmer, given that this is an intermittent failure likely due to a race condition specific to the test and not a condition we will see when the addon is deployed (users do not generally load several flash pages within a fraction of a second), and given that the flash plugin notification feature does work correctly with the addon installed under these more "normal" conditions, we have opted to note the failure, but not treat it as a blocker.

[biancadanforth]

Final testing in Treeherder - Analysis:

• Treeherder results for the latest build of the study on Release 59 with ./mach try -p linux64,win64,macosx64 -u all -t all (all desktop platforms, all unit tests, all performance tests).
  • Note: There was a bug in the artifact build process, so this is a full, non-artifact, build. See Addendum below for more details.
• Perfherder results
  • Baseline: the parent commit which was the tip on Release before adding my patch VS
  • my patch added on top of it on Release
• Notes for all unique test failures

Action items:

1. Add manual checks to TESTPLAN.md for QA to
   • Manually test that about:home/about:newtab works and is not super slow.
   • Manually test that the SSL indicator turns on when a page loads from about:newtab.
   • @rhelmer , can you confirm this indicator is the green lock icon and that is should appear as you load a page from about:newtab?
   • Manually test that the zoom button works.
2. Check Perfherder results for performance regressions.
   • Wondering if turning off browser.newtab.preload will cause any significant regressions.
3. Look at Treeherder results for Release and see which of these failures could be flagged as intermittent/flaky/also failing.
4. (Optional) Re-run some unit tests locally:
   • Run the following tests locally with and without the browser.newtab.preload turned back on in the study to see if it passes: (bc3, Linux x64 opt) dom/base/test/browser_aboutnewtab_process_selection.js, (bc6, Linux x64 Stylo Disabled Debug) browser/base/content/test/urlbar/browser_urlbarAboutHomeLoading.js, (bc3, OSX 10.10 opt) browser/base/content/test/newtab/browser_newtab_background_captures.js

---

Addendum:

I was having trouble with artifact builds both locally and remotely; the Treeherder results below confirm there is a bug in artifact builds currently. I have discussed this with nalexander in IRC, so he is aware. While I could not do an artifact build locally and had intermittent build failures for artifact builds on the try server, I could successfully create a non-artifact build locally and all non-artifact builds with my patch were successful on the try server.

Release channel, with study (v 1.0.3), artifact build Since today is merge day, per nalexander there is a bug in the build system for artifact builds (building locally or using a try build). I had intermittent build failures for ./mach try -p linux64,win64,macosx64 -u all -t all --artifact with an artifact try build. Here are the Treeherder results for an artifact build with my study as a patch.

_Release channel, no study, artifact build_ Also, per rhelmer's recommendation, I ran an artifact build try run without my patch on release with ./mach try -p linux64,win64,macosx64 -u all -t all --artifact. Here are the Treeherder results for an artifact build without my study.

[biancadanforth]

I discovered why I couldn't view any Perfherder results for my patch in Treeherder, thanks to help from osmose:

Background: I ran my study as a patch against Firefox Release (59) for a full, non-artifact build with the following ./mach try -p linux64,win64,macosx64 -u all -t all. This ran all performance tests ONCE. I am seeing Perfherder results of my patch compared to mozilla-release as having no baseline and Perfherder results of my patch compared to mozilla-central as having no overlap in which tests were performed.

What's going on?

Why I'm not seeing ANY baseline data for mozilla-release: The commit that was at the tip of the Release branch when I applied my patch has a Treeherder that had NO talos tests performed. mozilla-release is whatever branch the current release version of Firefox is based off of, so if I try to compare my TALOS tests to mozilla-release, I should expect to see nothing. Per osmose, a commit for Release that ran TALOS tests doesn't exist by default.

Why I'm not seeing any overlapping test results compared to mozilla-central: Firstly, comparing my patch on Release to mozilla-central isn't a good idea:

the release branch probably has a bunch of changes to which tests are run. Looks like all the tests central has that you don't have "stylo" in them. Also looking at the baseline tests, they have error ranges (e.g. +/- 0.5%), while yours do not. That's because the baseline tests were run several times, where mine were only run once each. This has to be made explicit in the try syntax to run tests multiple times.

What to do about it? To have comparable TALOS test results, I need a Try server run against Release that runs all the same tests as my patch does, and multiple times to get average values and a sense of repeatability/reliability of the test results.

1. Push the parent commit of Release to the Try server running all TALOS tests at least 5 times.
2. Push my patch added to that commit of Release to the Try server running all TALOS tests at least 5 times.

   If you go to https://mozilla-releng.net/trychooser/ and select "Both" for the build type, "linux64" for the platform, you get the following try syntax: ./mach try -b do -p linux64 -u none -t all Then, if you check the box on the right that says "To compare Talos numbers we need 5 retriggers" it adds --rebuild-talos: ./mach try -b do -p linux64 -u none -t all --rebuild-talos 5 Then those numbers will be comparable.

[biancadanforth]

Action Item: Look at Treeherder results for Release and see which of these failures could be flagged as intermittent/flaky/also failing.

Compared to the Treeherder results for the tip of Release on top of which I submitted my study as a patch, my study's Treeherder results have no failed tests in common. This means that these failures I am seeing are either intermittent, or the result of my patch.

I basically CMD + F searched for each of the 11 failed tests from Release in my summary document for the failed tests in my patch.

[biancadanforth]

Action Item: Check Perfherder results for performance regressions.

Perfherder results compared to the tip of Release

While my final patch is significantly slower than my mid-development patch; both Perfherder results had average performance regressions compared to the tip of either Nightly or Release without the patch between 10-15%.

See this spreadsheet (Sheet 2) for a comparison of performance tests from mid-development to final development. One reason why the final development results are considerably slower in an absolute sense than mid-development (outside of added complexity in general) is that I turned off browser.newtab.preload to be able to accurately measure the time the new tab page is opened.

One thing I could check to see is if turning browser.newtab.preload back on and re-running the same tests dramatically minimizes the regressions.

[biancadanforth]

Action Item: Update TESTPLAN.md

PR #188 adds 3 new tasks for QA to check for to ensure none of the unit test failures we were seeing have actually caused related functionality in Firefox to stop working.

[biancadanforth]

Okay per @rhelmer , the performance regressions are acceptable, and as long as QA verifies that the zoom button, SSL indicator and new tab page are functioning as normal with my add-on installed, we have Engineering sign-off.

[biancadanforth]

Performance Regression Testing Summary for Posterity

Aside: We had about 600,000 people in the Tracking Protection Messaging study. 75k people per branch for each of 4 branches for two distributions (one to new users; one to all users).

The only significant, repeatable performance regressions I had for the Tracking Protection Messaging study were largely in the 10-15% range compared to release without my patch using v4 StudyUtils. If you are seeing higher regressions than that, then I don’t think StudyUtils would be the primary cause.

I attribute my remaining performance regressions to implementation details of the study (turning off new tab preload, listening on every network request, having a less optimized implementation of Tracking Protection…).

The only performance improvement I made was to delay execution of my study-specific code during Firefox startup.