SVG loading icon & closes #29

[julianrichen]

Changelog:

• Loading icon has been changed from a gif to a svg animation, matches text color and looks sharper; also smaller then the gif.
• Context-menu change (closes #29)
  • Right-clicking page will use the current active tab url
  • Right-clicking a link will use the href's link

Sorry for not splitting these into two seperate commits, I forgot the fork my branch into a sub branch.

[IsSuEat]

Hi Julian! This seems to not work right here, for example when I click on a youtube preview image, the addon tells me that it couldn't find a plugin. On the link on the other hand it works fine. See here: https://vid.me/YBJm

Also with my current (pretty dark) desktop theme, I can't see the loading animation.

Greets, Armin

[julianrichen]

I think that is because it is seeing the element clicked is an img and not a a[href]. I'll see if I can fix it.

I wonder if we can check for dark variant themes and change the svg's color based on that.

[julianrichen]

Commit 5a19d9e should fix the element issue, however, it seems impossible on special elements. For example any of the "Live" stream boxes on the homepage of HitBox.tv will not work because the links are generated with JS...

As well I learned certain media on YouTube (for example Vevo music videos) can not be played with Livestreamer because it is encrypted, might be worth improving the error messages depending on what Livestreamer says.

Still looking into the dark varient issue.

[IsSuEat]

What I dont understand atm is: why does clicking the image with the current version work, but with your version it wont. It seems like the selectorContext is important how the node and data are passed. Specifying * as selectorContext doesn't seem to do the trick either.

[julianrichen]

~Edit~ Answer your question: Because of this line node.tagName.toLowerCase() === "a" && node.href !== "". Instead of using selectorContext to filter the links which calculate objects being wrapped (like a[href] wrapping an img). My method was checking the object (node) clicked, because the element being right-clicked was an img the node.tagName.toLowerCase() return img instead of a.

I was not aware of this and believed only one selector could be used at a time. I later learned you could do contextMenu.SelectorContext("a[href], body"). Which is the equivalent of a css selected, ex:

.my .example, .my .example_2 {

}

I rather smart approach once you realize you can do it.

---

About the theme color issue:

As I continue to work on the style issue I'll share my experience, maybe someone might find it interesting.

So the short answer is as of July 2nd, 2015 no method exist to test if the users' current theme or default system settings has a dark theme installed. It has been proposed in this bugzilla report but it seems nothing was done.

My first goal was to find a way to test if the content should be darker or lighter then the background. I did this by calculating YIQ, which made me create a JS function.

I figured the above would be harder then finding the browsers/panel background color, however, I was wrong... I tried in data/js/globa.js to calculate the panel background color BUT it returns transparent... data/js/global.js

console.log(window.getComputedStyle(document.body, null).backgroundColor); // Returns transparent

Assuming it was set globally I tried the the browser window (XUL document) its self in lib/main.js once again it returns transparent.

lib/main.js

var browserDocument = require("sdk/window/utils").getMostRecentBrowserWindow(),
    browserStyles   = browserDocument.content.getComputedStyle(browserDocument.content.document.body, null).backgroundColor,
    browserStyles2  = browserDocument.content.getDefaultComputedStyle(browserDocument.content.document.body, null).backgroundColor;
console.log(browserStyles); // Returns transparent
console.log(browserStyles2); // Returns transparent

As you can see I'm calculating the computedStyle over just style since style is the inline style set by the user, rather then system.

Not really sure what else to try. I wanted to get this to working so we could also change other styles in the panel like the border color. I see in the video above it's set to #cccccc when it would be better to have a darker color like #111111.

I'll keep experimenting, maybe parsing the systems chrome://browser/content/browser.css or chrome://browser/content/browser.xul will do the trick, not sure if this effects users themes.