Skip to content
This repository has been archived by the owner on Oct 28, 2019. It is now read-only.

How to upgrade from the upstream Firefox theme

Jump to bottom
Alexander Seleznev edited this page Oct 30, 2013 · 7 revisions

(This text is originally from issue #127)

Have a vanilla branch

Switch to a vanilla branch (the previous version of Firefox is committed), remove the directories and re-add from the Firefox zip. There are special directories that have to be extracted and put in the right place for a theme.

How to extract from Firefox:

  1. Download the official ZIP
  2. Extract omni.ja and browser/omni.ja to a temporary directory as omni.ja and browser-omni.ja
  3. Use the command-line unzip too to extract (as file-roller can't handle it)
  4. Wade through the directories to find the correct ones to copy to the (now-blank) locations in the repo's vanilla branch

Then, I basically copy the following directories over to the theme/chrome in the vanilla branch:

  • chrome/browser/skin/classic/browser
  • chrome/browser/skin/classic/communicator
  • chrome/toolkit/skin/classic/global
  • chrome/toolkit/skin/classic/mozapps

Now, I git add . in the theme/chrome and git commit -a.

Then the fun task of merging in the changes and fixing conflicts begins! (It's usually not too bad, unless there's been a lot of theme churn on both sides.)

Starting the merge

Oh, naturally, I when merging the commits, start in a new branch (something called update-to-##, like update-to-16), and that's where I'm doing this upgrading business. First step was to do a git merge vanilla and now it's the conflict resolution. When this is done, commit and push the branch to the repo so everyone can start playing with fixing up whatever the merge may have broken.

Update: I've found that doing a git cherry-pick of the commit id of the latest changes in the vanilla branch is an easy way to merge the changes.

For commits

Do a git status and look for easy visual changes (basically PNGs and SVGs). Having git auto-color its output really helps here. If there are conflicts there, I checkout whatever version is appropriate. There's no harm in doing multiple checkouts, either. You can also do a git log path/to/file.png to see what commits have happened, to help determine what has happened. If we havn't done anything relevant there, then a git checkout vanilla path/to/file.png else, git checkout master path/to/file.png — and again, you can check out one and the other and look in Nautilus to see it auto-update with a preview if you're not sure.

To get git colored output: git config --global color.ui true

The "fun" part is resolving all the CSS conflicts, especially in browser.css. That's where I'm at now.

Dealing with conflicts

When you're trying to determine what happened in a conflict, you can reference this by using git blame path/to/file.css. At the leftmost side, there's a git commit id that you can use as a reference to see what happened. To view the lines changed, do a git diff 69fdbb0c^ 69fdbb0c (if the commit id is 69fdbb0c, for exmaple). This will let you view the changes between previous commit to that id (hence the ^) and the id itself. You can then look for the offending line and figure out how to resolve the commit.

Resolving might be:

  • accepting our change
  • accepting Mozilla's change
  • adding Mozilla's change
  • manually writing a new change that incorporates ours and Mozilla's in some way (this happens sometimes when the CSS rule and its properties change independently)

So, yeah, fun times. There are a lot of conflicts, especially in browser.css. I'll try to get this done though.

Clone this wiki locally