This is a continuation to my previous blog on setting up Brackets, Thimble and choosing a bug to work on. Now that I have my local instance of Thimble installed, I can start working on the bug.
Bug to fix
The issue here is that renaming a project is not recognized as a change in an already published project, so the “Update published version” button is not available.
- For example, an already published project named: ‘My Project’
- Rename it to ‘My Project renamed’ and click ‘Save’:
- Now if we click on the ‘Publish’ button, the ‘Update published version’ button is not available after renaming the project:
Setting up workspace
In the previous post, I set up my local Thimble instance by Forking thimble.mozilla.org into my repo, then cloning the project from my repository. To start working on this bug, I created a new branch (lkisac_issue_719). This guide explains how to set up “Persistence with DevTools Workspaces”, so that I could edit the files on my local machine and have the changes applied server-side on a browser refresh. This is essentially done by mapping files/folders to your local computer.
Drag and drop your local project folder (thimble.mozilla.org) to the Source navigator pane in DevTools.
You can right click the filename in the Sources editor, then select ‘Reveal in navigator’ to make sure the file your working on is the one from your local folder.
Vagrant had to be reloaded each time in order to see the changes. This was fixed in this commit, so I pulled these latest changes to my repository.
I also had an issue with my vagrant commands returning this error:
There was an error while executing `VBoxManage`, a CLI used by Vagrant for controlling VirtualBox. The command and stderr is shown below. Command: ["showvminfo", "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"] Stderr:
Earlier while I was running ‘vagrant up’ I ran into the Windows BSOD (blue screen of death) which interrupted vagrant’s start up. After restarting my computer and running vagrant commands, I would get this error. I searched online for related issues but could not find a solution that worked (including doing a clean installation of vagrant and virtual box and following some suggestions from here). I finally came across this thread where the “.vagrant” file was mentioned. This is a metadata file that stores project info and must have been gotten corrupt when vagrant was interrupted. I tried moving this file outside of my project folder and was able to get vagrant up and running.
During development, one thing I ran into sometimes was after leaving thimble running in vagrant for a while then coming back to it, I would suddenly run into some 401 errors on my Thimble instance. A few ways I got around this was to:
- Select ‘Disable cache’ under the Network tab in DevTools (this is a useful setting while doing web development for any cached data to not interfere while testing. It won’t affect your regular browser’s cache settings)
- Sign out of Thimble account then sign back in
One of the maintainers provided some guidance on which sections of code would need changing. There were 5 files I modified in the code.
- Changed handleFileEvent to be on the Publisher prototype
- Renamed handleFileEvent to showUnpublishedChangesPrompt
- Moved ProjectRenameUtility.init call to bramble-ui-bridge.js
- Added ProjectRenameUtility to BrambleEditor create options
- Now contains call to ProjectRenameUtility.init() after publisher init
- init function receives csrfToken, appUrl and ProjectRenameUtility
- Pass csrfToken, appUrl and ProjectRenameUtility to BrambleUIBridge.init call.
- Call new showUnpublishedChangesPrompt from rename utility’s save function
- Include publisher in the require, stored in
- Added publisher and bramble parameters in ProjectRenameUtility constructor and stored in
Setting up breakpoints in DevTools was really useful for working through the code and testing functionality.
Example for setting a breakpoint at line 343
You can click on the line number in the online Sources editor to set the breakpoint.
Then step through the code with these commands (similar to Visual Studio):
F10– step over
F11– step in
Shift + F11– step out of function
After much trial and error, I was finally able to see the ‘Update published version’ button after renaming the project.
Create Pull request
After I was able to get the expected results, I committed my changes to my lkisac_issue_719 branch and created my Pull Request.
When you commit code to open source projects, there will be one or more test builds that will likely need to be run to check if the code is valid with those tests. After pushing my changes to git, my first commit failed in the Travis CI build. It was noted that the bramble object in project-rename.js was undefined. So I fixed it in this commit, and the build passed successfully.
Additionally, the maintainer also provided some feedback so they could fully land this patch in Thimble. So I went back into my workspace, made the necessary changes, tested the functionality again, and committed the changes back to git.
The most difficult and time consuming part for me in this whole process was getting my workspace set up properly before even getting started on the code. Once I was finally set up and able to write and test code, it was a good experience working on the Thimble code and contributing to this open source project.