389COM: Mozilla

Dr Carey Pridgeon, DR Nazaraf Shah

Created: 2017-09-15 Fri 12:12

Mozilla Lecture

Starting the process

  • To begin with, get the Mozilla source code and finish it to do the initial setup (follow the accompanying Mozilla Build Worksheet).
  • Once you've done this, and you have your Bugzilla account, use this lecture as a reference point.
  • All subsequent Mozilla work on this module assumes you have completed the worksheet.
  • Make completing it a priority, all questions will be answered with have you done the Mozilla worksheet first.

Choosing a bug - 1

  • Mozilla have a nice website for choosing bugs to fix Moz Bugs.
  • This particuler website was created by two students on this module and adopted by Mozilla.

Choosing a bug - 2

  • simple (includes all good first bugs)
  • Good first bugs are the place to start when learning the process.
  • Unassigned bugs
  • Diamond Bugs, like their namesake, are very hard.
  • Choosing neither simple nor Diamond bugs would show all bugs.
  • To gain any marks on a bug, simple or not, there must be at least evidence of an attempted fix.

Bug Fixing Process Guides

Creating a patch

  • Patches create changesets that contain your source code changes.
  • The command to create patches is hg qnew patchName
  • The hg part is because this is a command in the hg toolset.
  • This command will write a patch to the hidden folder .hg/patches in your source directory.

Editing the code - 1

  • Before you start working on a patch, always update your source tree with hg pull
  • Once you've edited your code to create a patch for submission, you need to clean your source code tree.
  • to revert your code to a pre edit/pre patch creation state hg strip tip –force

Editing the code - 2

  • If that doesn't work, just delete the source tree and set off a fresh clone. This isn't an ideal solution, but it is simpler then going through the other options.
  • hg clone https://hg.mozilla.org/mozilla-central/ firefox &
  • If you hit any other problem where patch creation, or pulling the latest revision won't work, try these as well.
  • You will need to run mercurial setup again if you re-clone the codebase.

Submitting your bug for Review by Mozilla

  • The process used to involve simply attaching your patch to the Bugzilla thread, and some Mentors may still allow this for temporary review, but we require that you use the use the new process, as it in line with the modules philosophy of exposing you to tools and processes you will encounter in the workplace.
  • Now Mozilla have instituted a much better bug submission and review system, which will avoid many of the problems we have encountered in the past, called MozReview. To use it, you need to commit your bugfix to Mozreview.

Mozilla Development Environment

  • Basic instructions on how to begin the bug submission process can be found here. For ease of use we recommend sticking to using the official Mozilla Virtual Machine for all Mozilla bug fixing.
  • However, for those of you who want to, you can set up your own system to compile Firefox, here are the directions for the various platforms you will likely use Windows, Linux, Mac. But, we won't be supporting this method, as it is often fraught with problems.
  • Virtual Machines have the advantage of not messing with your normal system setup.

Obligatory XKCD

perspective.png

  • Copyright: Randall Munroe - XKCD
  • Mirrored in my hosting to avoid bandwidth stealing

Licence for this work

  • Licenced under Creative Commons Attribution-ShareAlike 4.0 International by Dr Carey Pridgeon 2016
  • (Licence does not cover linked images owned by other content creators)