Opened 5 years ago

Closed 5 years ago

#16090 closed task (fixed)

Review Firefox Developer Docs and Undocumented bugs since FF31esr

Reported by: mikeperry Owned by: mikeperry
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: ff38-esr, MikePerry201505, TorBrowserTeam201506, tbb-5.0a3-essential, MikePerry201506
Cc: arthuredelstein, gk, brade, mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The Developer Docs are here: https://developer.mozilla.org/en-US/Firefox/Releases/38.

There also used to be a link to a bugzilla query for undocumented bugs for each release, but those seem to have disappeared... Hrmm..

Child Tickets

Change History (22)

comment:1 Changed 5 years ago by arthuredelstein

Cc: arthuredelstein added

comment:2 Changed 5 years ago by mikeperry

Firefox 38:

Firefox 37:

Firefox 36:

Firefox 35:

Firefox 34:

  • Fingerprinting:
    • Performance.now is exposed to WebWorkers

Firefox 33:

  • Nothing I noticed

Firefox 32:

I will be editing this comment as I dig into all of these items in more detail.

Last edited 5 years ago by mikeperry (previous) (diff)

comment:3 Changed 5 years ago by gk

Cc: gk added

comment:4 Changed 5 years ago by mcs

Cc: brade mcs added

comment:5 Changed 5 years ago by gk

https://bugzilla.mozilla.org/buglist.cgi?bug_status=RESOLVED&product=Core&query_format=advanced&resolution=FIXED&target_milestone=mozilla32&order=priority%2Cbug_severity&limit=0

and

https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&product=Core&target_milestone=mozilla32

were the URLs I used for Firefox 32. I plan to do the same for 33-38. I'll do one version per day to keep my sanity and minimize the risk for overlooking things.

I found nothing in addition to comment:2. Notes: KeyboardEvent.code landed already in Firefox 32. A user had filed a bug a while ago which I re-purposed (#15646). The Data Store API is only available for Firefox OS.

comment:6 Changed 5 years ago by mikeperry

Keywords: TorBrowserTeam201506 added; TorBrowserTeam201505 removed

comment:8 Changed 5 years ago by gk

Just for posterity: the new Cache API landed in Firefox 32 (#13035) and HTTP/2 got enabled in Firefox 35 (https://bugzilla.mozilla.org/show_bug.cgi?id=1088910) and our #14952.

comment:9 in reply to:  2 Changed 5 years ago by mcs

Replying to mikeperry:

Firefox 36:
...

  • -remote was removed from the command line args. Does this mean our remoting prevention hacks may break?

I think we are OK. As it turns out, Mozilla restored the -remote command line flag in Firefox 36.0.1 after a lot of people complained. Arthur already rebased the #11641 patch and it looks OK.

comment:10 Changed 5 years ago by mcs

Firefox 34 added https://developer.mozilla.org/en-US/docs/Web/API/Device_Storage_API which is Yet Another Scary API That Is Disabled Via A Preference. Actually, it looks like it is on for Android (and Firefox OS). So this is another thing to keep and eye on; the pref is device.storage.enabled.

comment:11 in reply to:  2 ; Changed 5 years ago by gk

Replying to mikeperry:

But not cross-origin. We might want to check that we and Mozilla are talking about the same things here but I am slightly optimistic that this is not an issue for us.

comment:12 in reply to:  11 Changed 5 years ago by gk

Replying to gk:

Replying to mikeperry:

But not cross-origin. We might want to check that we and Mozilla are talking about the same things here but I am slightly optimistic that this is not an issue for us.

Reading further this seems to break out of our URL bar isolation :(. I've created #16300 for it.

comment:13 Changed 5 years ago by gk

I am done now reviewing the Mozilla bugs and the Firefox bugs, finally. I added #16316 as a result. The other bugs are coming tomorrow.

comment:14 in reply to:  2 Changed 5 years ago by gk

Replying to mikeperry:

Quoting from the spec

If utfLabel is not a label for utf-8, utf-16be, or utf-16le, throws a RangeError.

So, we have basically only utf-8 and utf-16le available across all supported platforms. I tested that a bit and can confirm that. Should be a non-issue then.

comment:15 Changed 5 years ago by gk

Okay, I think I am done with filing all the tickets. While looking at all the Mozilla bugs I realized that we might want to have a slightly different process next time mainly for two reasons:

1) If we are switching to, say, ESR 45 we should get started as soon as possible fixing/neutering new features to test as much new patches in the one alpha we usually only have. Thus, it makes more sense to have the bug review 39-44 already done by then (and a lot of the resulting ticket prioritization). This way we can identify critical things earlier and react better to them making sure they get definitely into the alpha.

2) Having the feature review (almost) in parallel with upcoming Firefox releases gives us the option to backport/develop fixes we may/could need for ESR 38 but Mozilla does not deem important enough for an ESR release.

What I have in mind would look like the following: As soon as we get our ESR 38 based Tor Browser out one of the team is catching up on the Firefox for developers documentation (this seems to cover the most important and most difficult to patch things and should therefore be enough for the first pass). Then we can review new features shortly after new Firefox versions get released (and think about fixing things for our ESR 38 based Tor Browser if needed). When we start preparations for ESR 45 we basically have all the ff45-esr tickets filed, and ideally prioritized, resulting out of Firefox 39-44 feature reviews. What is needed on the review part then are only the news coming with ESR 45 and double-checking the undocumented bugs and the ones with milestone Firefox39-45.

We won't save time this way but if all goes well we should have more time to get ESR 45 features fixed and tested for the alpha and if needed we would be able to plug holes in ESR 38 with little effort. Seems to be worth it I think.

That could be part of a review-dev-docs-and-bugs-guide (including proper bug URLs (like the one in comment:7)) documented somewhere in our spec repo.

comment:16 in reply to:  15 ; Changed 5 years ago by mcs

Replying to gk:

What I have in mind would look like the following: As soon as we get our ESR 38 based Tor Browser out one of the team is catching up on the Firefox for developers documentation (this seems to cover the most important and most difficult to patch things and should therefore be enough for the first pass). Then we can review new features shortly after new Firefox versions get released (and think about fixing things for our ESR 38 based Tor Browser if needed). When we start preparations for ESR 45 we basically have all the ff45-esr tickets filed, and ideally prioritized, resulting out of Firefox 39-44 feature reviews. What is needed on the review part then are only the news coming with ESR 45 and double-checking the undocumented bugs and the ones with milestone Firefox39-45.

This is a good idea and should allow us to scope the work earlier for the next ESR release. Should we make this part of the release procedures? How will we remember to do it?

comment:17 in reply to:  16 Changed 5 years ago by arthuredelstein

Replying to mcs:

Replying to gk:

What I have in mind would look like the following: As soon as we get our ESR 38 based Tor Browser out one of the team is catching up on the Firefox for developers documentation (this seems to cover the most important and most difficult to patch things and should therefore be enough for the first pass). Then we can review new features shortly after new Firefox versions get released (and think about fixing things for our ESR 38 based Tor Browser if needed). When we start preparations for ESR 45 we basically have all the ff45-esr tickets filed, and ideally prioritized, resulting out of Firefox 39-44 feature reviews. What is needed on the review part then are only the news coming with ESR 45 and double-checking the undocumented bugs and the ones with milestone Firefox39-45.

This is a good idea and should allow us to scope the work earlier for the next ESR release. Should we make this part of the release procedures? How will we remember to do it?

Maybe create tickets with TorBrowserTeam2015MM tags (where MM is the month)? I'm happy to do this if you think it's a good idea.

comment:18 Changed 5 years ago by mikeperry

Keywords: tbb-5.0a3-essential added

Tag the set of things we should aim to understand/fix for the fist FF38-based TBB (5.0a3, on June 30th).

comment:19 Changed 5 years ago by mikeperry

Keywords: MikePerry201506 added

comment:20 in reply to:  16 Changed 5 years ago by gk

Replying to mcs:

Replying to gk:

What I have in mind would look like the following: As soon as we get our ESR 38 based Tor Browser out one of the team is catching up on the Firefox for developers documentation (this seems to cover the most important and most difficult to patch things and should therefore be enough for the first pass). Then we can review new features shortly after new Firefox versions get released (and think about fixing things for our ESR 38 based Tor Browser if needed). When we start preparations for ESR 45 we basically have all the ff45-esr tickets filed, and ideally prioritized, resulting out of Firefox 39-44 feature reviews. What is needed on the review part then are only the news coming with ESR 45 and double-checking the undocumented bugs and the ones with milestone Firefox39-45.

This is a good idea and should allow us to scope the work earlier for the next ESR release. Should we make this part of the release procedures? How will we remember to do it?

I thought about adding instructions to our tor-browser-spec repo in the audits folder describing the procedure: one of the team has the task of keeping track of the Firefox features and is filing the respective tickets and estimating their importance + tagging them with ff45-esr (to take the example for the next release).

Last edited 5 years ago by gk (previous) (diff)

comment:21 Changed 5 years ago by mikeperry

gk - Can you file a new ticket for the process updates (or just commit an outline to the spec repo) and then close this one? It looks to me like the original work in this ticket is done.

comment:22 Changed 5 years ago by gk

Resolution: fixed
Status: newclosed

I don't have permissions to commit to the spec repo, thus I created a ticket: #16444. It is for the ff38-esr time frame to get us properly started once the prepare-ff45-esr circus is beginning (which is basically as soon as we got Tor Browser based on esr38 out :) ).

Note: See TracTickets for help on using tickets.