Opened 8 years ago

Closed 8 years ago

#7248 closed task (fixed)

Review+Audit Firefox 16 and 17 for next FF ESR release

Reported by: mikeperry Owned by: mikeperry
Priority: High Milestone:
Component: Firefox Patch Issues Version:
Severity: Keywords: tbb-rebase MikePerry201302d
Cc: g.koppen@… Actual Points: 12
Parent ID: Points:
Reviewer: Sponsor:


We're going to need to start shipping FF17-ESR 'qualify' releases likely starting in December. We will need to switch over to FF17-ESR from FF10-ESR in mid-February or early March.

Here's the schedule:

Here's the developer urls:

In addition, I want to review the all FF17-ESR network glue code for changes to the proxy and DNS behavior, especially with respect to new HTML5 features.

Child Tickets

#7078closedmikeperryTorbutton causes Firefox 16 to crashTorBrowserButton
#7465closedmikeperryRebase Firefox Patches for FF17-ESRFirefox Patch Issues
#7937closedmikeperryRemove NoScript blocks of WebFontsFirefox Patch Issues

Change History (14)

comment:1 Changed 8 years ago by gk

Cc: g.koppen@… added

comment:2 Changed 8 years ago by mikeperry

Nick also wants me to investigate the situations under which Firefox does SOCKS resolves vs direct hostname connections, and how it decides to pin those responses.

comment:3 Changed 8 years ago by mikeperry

Keywords: MikePerry201301d added; MikePerry201212d removed

comment:4 Changed 8 years ago by mikeperry

Since I am going to dig into the networking code for this, I guess I should also test/verify that the mess of nonsense in #7656 and #7657 are actual bugs for us, and that the proposed fixes make sense.

comment:5 Changed 8 years ago by mikeperry

From the Firefox 16 developer notes, the following things need deeper investigation/code review:

I have not yet gone through the undocumented bugs. Those are here:

Thankfully, the Firefox 17 developer notes don't have anything terribly concerning. However, the undocumented bugs still need review. They are here:

comment:6 Changed 8 years ago by mikeperry

Concerning/interesting undocumented FF16 bugs: - Content can query Desktop idle status?? yikes - scrolling resolution info. Fingerprinting? - Might allow us to drop our flash patch?

There's also a handful of 'webapp' APIs that may or may not be concerning. I assume they are only active if you actively agree to 'install' a webapp on B2G. Most of them seem to be disabled/break on desktop.

comment:7 Changed 8 years ago by mikeperry

Undocumented FF17 bugs: - Can we constrain our window sizes with this? - Disk leaks?

Misc WebApp/B2G shit that we should verify doesn't leak to the Desktop/Disk/other profiles/etc:

comment:8 Changed 8 years ago by mikeperry

Here's the WebApp APIs that need code review investigation: - Can global activities be detected by third parties? - ditto for apps in general - Pretty sure we want to remove this or always lie

comment:9 Changed 8 years ago by mikeperry

And here's my final, canonical code review/url checklist:

Stuff that might actually help us:

comment:10 Changed 8 years ago by mikeperry

Keywords: MikePerry201302d added; MikePerry201301d removed

comment:11 Changed 8 years ago by mikeperry

Bleh, the Social API is also present and enabled in FF17.. Odd that the only place it was mentioned was the FF17 release notes and none of the developer documentation or DOCNEEDED bugzilla bugs:

comment:12 Changed 8 years ago by mikeperry

Here's the results of the audit so far:

During the network audit, I noticed that WebRTC snuck in, and seems to get built. Not sure if it is exposed to content yet, but it has code to initiate UDP sockets independent of the proxy settings. I filed #8178 to disable it (it has a build flag, thankfully). Everything else seems solid and more or less the same wrt networking.

CSS calc, currentColor, and scrollMax all seem benign. Calc supports numbers (pixels and percents) only. The Idle API was disabled at the last minute for normal content, but is still available to "WebApps" and extensions.

As for the other WebAPP APIs and WebApps in general, I am conflicted over disabling them vs allowing them but recommending against them in the FAQ (similar to what we do with extensions). If we decide to disable them, it looks like that is also just a build flag (--disable-webapp-runtime).

The Social API appears to be disabled by default through the pref 'social.enabled'. It has a whitelist with facebook in it ('social.activation.whitelist'), but a false value for the 'social.enabled' pref appears to override the whitelist.

comment:13 Changed 8 years ago by mikeperry

Actual Points: 12

The plugin thing doesn't help us. It's in the wrong place to fully prevent plugins from loading into our process space.

I added a note about the window size thing to #7255.

comment:14 Changed 8 years ago by mikeperry

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.