Blog

Open Source

Brave: First attempt to fetch desired Information

For release 0.3, I have chosen to fix issue issue #6856 in the open source project Brave. This has proven to be quite the deceptively difficult issue. So much so that at the time of writing, I have yet to successfully fix it. In this post I hope to share my experiences trying to find a solutions.

The Issue:

The poster of the issue desired to have the “about:brave” page show additional information, namely the user’s DPI scaling on a windows machine, but a another user expanded to also include the OS built number, resolution, graphic board driver and name. While not too bad initially, it later proved to bear unforeseen challenges.

Potential Solutions:

I was able to quickly discover the file that populated the about page, and immediately began searching the web for sources of the above mentioned items.

First I began looking for a source of DPI scaling. This was a largely fruitless endeavor, as many search results pointed to irrelevant problems and solutions, all except one chrome://GPU.

chromeGPU

This was what I was looking for. I have search the internet for the source code of the chrome web browser and began to analyze it. Picking it apart trying to figure out how it got these specs and how to incorporate it into brave. Alas I have hit a snag. To acquire the information, chrome uses a function called browser-bridge. This function is dependent on a file called cr.js, which is reliant on the use of DHTML. This ended any hope of incorporating it into Brave, as Brave does not use DHTML and I don’t know how to work around it. This was my best lead to find the DPI.

Failing to assimilate chrome’s GPU page, I have switched priorities to focused on getting the other items to display. Specifically the resolution. While I have come across many potential solutions, none really sickout in mind at the time of writing, I have settled with the library ,systemInformation. It has proven(in some cause) to be compatible with Brave, when getting memory, and CPU specs. Unfortunately, it can’t seem to detect the monitor nor the GPU of my laptop. I intend to test it on other devices or potentially relocate the fetch to another file.

This is what I have at the moment:

outPut

 

Open Source

URL: we need some space

For lab 6 of DPS909, we were tasked with fixing a bug in the open source project, Brave and then write tests to confirm the fix. This bug caused file addresses with a space to bring up the result of the user’s default search engine instead of the contents of the address. We’re given the following scenarios:

  1. "dog"
  2. " dog "
  3. "dog cat"
  4. " dog cat "
  5. "https://www.google.ca/search?q=dog"
  6. " https://www.google.ca/search?q=dog "
  7. "https://www.google.ca/search?q=dog cat"
  8. " https://www.google.ca/search?q=dog cat "
  9. "file:///Users/humphd/repos/browser-laptop/dog cat.txt"
  10. " file:///Users/humphd/repos/browser-laptop/dog cat.txt "

The first four cases worked as any other browser, running the given text through the user’s default search engine. Scenarios 5-6 also ran like any other browser, navigating to a google search of “dog”.

working5-6

Scenarios 7-8 on the other hand ran the address though the default search engine.

working7-8Scenario 9-10 had similar results of other web browsers, displaying the contents of the file with chrome being the only one that does not require “file///” in the beginning.

working9-10

It seems the Brave is capable of folding the spaces that are in either end of the address but spaces caught anywhere in the middle will cause the URL to be seen as invalid and sent to the default search engine.

To fix this I have looked to see how other browsers handled these scenarios and I have noticed that they replace and space in the middle of a URL with “%20”. I have added the following to replicate this process.

let str = input.trim().replace(/\s([^\s]+)$/, ‘%20’)

It worked without a hitch.

working7-8

When writing the tests, I only needed to create two tests (one for each of the failed scenarios). And just like that, it was done.

 

 

Open Source

Let there be night… mode

For lab 5 of DPS909, we were tasked with implementing night mode to an open source project called Bridge Troll.

Bridge Troll is a browser based geolocation game that has the user unlocking bridges by getting within a certain distance of them.

day

As you can see it’s almost all white which can make it hard on the eyes when used during the night. This is the purpose of this feature.

One of the requirements of this feature is to have it switch between day and night mode is to avoid cluttering the UI with addition buttons or menus but instead use libraries , such as mourner’s suncalc, to determine if sun has set on the user’s current location. I have also looked for dark layout for the leaflet map along side appropriate icons to substitute into the application when it’s determined to be night time in the user’s current location. I had some difficulties putting it all together but this was more due to my editor than anything else. But I must say I am rather happy with the end product.

night

Open Source

Standards for Automated Testing

For lab 4 of DPS909, we were tasked with expand test suite,  tc39/test262, with the intention of familiarizing ourselves with reading and writing tests.

The first step was to download the test suite from GitHub and run all the tests, but I have hit an unforeseen error that I couldn’t solve.

error

Despite this error, I had to press forward in whatever way I could. I have studied the existing tests of Array.prototype.reverse and ArrayType.prototype.reverse, and found a potential addition to the suite. The idea behind this assertion is to see how push function affects reversed array. But due to the above mentioned error I couldn’t run it to see the result.

 

Open Source

Release 0.2 – First Pull Request

During the last week I have been working on issue #1511 in the open source project AVA. The AVA watcher should only run test files if they or their .snap files are changed or deleted in the case of the latter. The above mentioned issue has pointed out that if any of the .snap files are deleted all given test files are run instead of just the ones that had theirs deleted. I have ultimately fixed this issue with a single line change but getting to that point took quite awhile and the pull request was yet to be accepted at the time of writing.

When starting on this issue, I first needed to reproduce this bug. The steps needed to reproduce this issue go as follows:

  • write complex data processing code
  • feed it example data in tests with t.snapshot()
  • inspect result .md file in editor tab
  • if snapshot is no longer good, remove .snap file so it gets regenerated

I had little experience using AVA, much less its more advanced pieces of features such as snapshot tests and watchers. This part definitely taken the most time, as I pour through their docs and examples to recreate the environment. To save time I used google-libphonenumber from DPS909 Release0.1 to serve as the complex data processing code. Then I have plugged it into t.snapshot() as seen below:test2I ran the test and an .md file was created containing its output. At this point, I was stuck for quite a bit as I wasn’t sure why the .snap file was not regenerating after its deletion. It turned out that a watcher was needed to set to check if any of the source files have been tampered with. This was not stated in the original post but was indirectly mentioned in one of the comments. After the watcher was set the .snap file was now regenerating. To properly test this I needed multiple test files so I settled with 2 files, each having 3 tests, test.js and test2.js. The image below shows me deleting test2.js.snap while the watcher was running and shows that 6 tests passed when it should of been 3 since test2.js only has 3 tests.unfixedThis shows that I has successfully reproduced the bug mentioned in issue.

The solution to the bug was pretty simple. While the watcher can recognize that one the source files was altered, it didn’t associate the deleted .snap file with its test file. Thus the system just ran all given test files to regenerate missing .snap files. The change and its screenshot tests can be seen in the pull request.

The pull request has yet to go through. I was asked to change its name and it did fail one of the checks. Now I am just waiting on further instruction.