Here i ask for Pale Moon support: https://addons.mozilla.org/de/firefox/addon/canvasblocker/reviews/660262 because the 1.3 version works but not the 1.4
Pale Moon have currently not the Components.utils.exportFunction API, but the developer found the implementation bug entries (http://forum.palemoon.org/viewtopic.php?f=5&t=7015&p=45353#p45353). It is not so easy to implement this, so is Components.utils.exportFunction realy needed?
If the same functionality can be achieved with the API that is part of Pale Moon (as Moonchild may say in his post) I can do so - but I do not know how (and currently have no time to investigate too much).
If you (or Moonchild) can give me a hint how I can do the same with "[r]egular sandboxing calls" I'm happy to try it.
But there is no way I will switch back to mechanisms I used in 0.1.3 because they are really hard to maintain and some features I plan to include will not work at all.
Moonchild post this:
Um, it all depends on what exactly the dev wants to do and how they want to do it.
I (nor others on this forum) can do that kind of development in the dev's stead.
I understand the position though - the extension has been developed for Firefox; Pale Moon support has not been considered when designing the new code that employs exportfunction. So it's a rock and a hard place (at least for me): I don't have the time to do extension development; I'm not sure if others here have the knowledge or expertise to look into this and willing to invest available free time to examine sandboxing routines (once it is known what "some planned features" and the reason for switching to exportfunction (what exactly was so hard to maintain?) are) and doing extension development to implement an alternative. As said sandboxing can likely be used, but it's hard to tell without examining the extension code up close.
I want to add some GUI features that require some sort of communication between content script and addon. Therefore the old way (creating the functions that live in the context of the page with new unsafeWindow.Function(...), which is very ugly, unmaintainable and not good style) is not feasible.
I just need a way to overwrite some functions in unsafeWindow.HTMLCanvasElement.prototype that are able to communicate with the addon and can be called from a normal site script.
I get this answer from Moonchild:
If I correctly understand what he's trying to do (adding/changing functions of specific page elements), then he should look into XBL-binding his extension scripts to page content. That should allow him to access functions as seen from the page content side of the browser. As far as I understood the implementation, overloading should be possible without any problem.
See: https://developer.mozilla.org/en-US/docs/XBL and https://developer.mozilla.org/en-US/docs/XBL/XBL_1.0_Reference
XML Binding Language (XBL, sometimes also called Extensible Bindings Language) is a language for describing bindings that can be attached to elements in other documents. The element that the binding is attached to, called the bound element, acquires the new behavior specified by the binding.
Bindings can contain event handlers that are registered on the bound element, an implementation of new methods and properties that become accessible from the bound element, and anonymous content that is inserted underneath the bound element.
He could use some of the many add-ons that add buttons/controls to web pages as an example to draw from, how to add code to page content that can call extension code directly.
Note: he does have to set the binding to allow binding to untrusted content since v25.2 or it won't work.
XBL will not work because the overloading has to be done on every canvas to every time.
As stated here: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tutorial/Adding_Methods_to_XBL-defined_Elements one could generate a canvas with createElement and the overloading would not take place.
EDIT: and as far as I see in my tests the methods/overloads of XBL are completely hidden from the page scripts.
Maybe you can follow Moonchilds instructions:
Methods in XBL are supposed to be hidden from scripts in the actual page content. You bind the binding to the page, not the page to the binding.
I'm not sure what the dev is trying to accomplish exactly, but a bound page content script can manipulate any page (DOM) node in the loaded document, so that should suffice to block canvas elements. I'm not sure what else the dev is trying to do. XBL binding is usually used to add custom content to a page - if that's not what should be accomplished then they'd need something else and I apologize for misunderstanding.
I really don't have time to do their research into what dom scripting is needed to accomplish whatever task is attempted. If the dev wants to work with us, please let them come here themselves instead of passing it through a third person.
Any update on this problem? I like this addon vey much, but prefer Pale Moon.
Sorry - no progress in this project for the last months... so much to do so little time... ;)
But I will contact Moonchild on the other forum.
I tried to register to the forum (username: kkapsner) but do not get the activation mail... and I found no way to contact the administrators... can you please contact one of them or give me an email adress?
Hello!
Thank you for your support. I wrote Moonchild a message and wait now for a answer.
Maybe you get in this time your E-Mail.
Am 9. April 2015 12:04:34 MESZ, schrieb kkapsner [email protected]:
I tried to register to the forum (username: kkapsner) but do not get
the activation mail... and I found no way to contact the
administrators... can you please contact one of them or give me an
email adress?
Reply to this email directly or view it on GitHub:
https://github.com/kkapsner/CanvasBlocker/issues/15#issuecomment-91181141
Hi
Did your register work?
He write your email adress is invalid.
This is weird... palemoonforum AT mail DOT kkapsner DOT de is valid and functional...
Maybe the "palemoonforum" make problems.
Try a other one - maybe with user at kkapsner dot de
I reregistered with a simpler mail address and still do not get an activation mail...
false alarm... it just took very long.
Okay. Good if it works now.
The long time is maybe because the admin need to allow it i think.
How is the process with Pale Moon?
Maybe take a look if the new version makes things easier for support PM.
https://forum.palemoon.org/viewtopic.php?f=5&t=8474
I'm sorry. There is no progress. In the meantime you have to use 0.1.3
This new features do not help in our case. So to support Pale Moon I have to build a separate branch that does not use exportFunction()...
Which features do you think are the most urgent ones to be available in Pale Moon?
I like all your new options. The "best" is give the webseite fake data,
OK - let's see when I have time to port the fake functionality to the old function export technique.
Maybe their is no need to add the fake data feature because the new PM beta add this feature.:
Canvas data poisoning option (canvas.poisondata) - set to true to make getting data from a canvas tainted with random, but human-imperceptible changes. This should kill any hash-based canvas fingerprinting at the expense of speed in the functions in question (toDataURL() and getImageData()).
So then you can make add the other features? :D
I made major code changes in the withoutPageMode-branch (https://github.com/kkapsner/CanvasBlocker/blob/withoutPageMod/canvasblocker.xpi ). Can you please check if the addon now runs in Pale Moon? Thank you.
Thanks for your support!
The version works, but i need to add this code to the install.rdf:
<em:targetApplication>
<Description>
<em:id>{8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}</em:id>
<em:minVersion>25.0</em:minVersion>
<em:maxVersion>35.*</em:maxVersion>
</Description>
</em:targetApplication>
After that, the addon install works.
Anyway i wonder why you remove the "ask" options. "Vortäuschen" exist in Pale Moon nativ as i write and works like with your addon. So i would like when you add the "ask for readout API permission" feature.
I removed these options because I thought nobody uses it (and they needed some work after the code reorganisation). Since I was wrong I added them in the last commit.
Please tell me if it works as intended.
PS: The install.rdf must be changed again...
Works great! Thank you.
Yes, after add Pale Moon in the install.rdf the install works.
Great.
0.2.1-Release is the last version which works with Pale Moon.
Have you plans to support Pale Moon?
@kkapsner: Could you please help us out one more time with v0.2.2 and add an xpi download file specifically for us?
Created a release that can run under seamonkey and palemoon: https://github.com/kkapsner/CanvasBlocker/releases/tag/0.2.2-OtherRelease
But no warranty...
Thanks. The install work (without any modification) but the setting button doesn't.
Click on it return to canvasblocker addon info.
Hm... it seems that Palemoon does not include a copy of the current sdk and is therefore not compatible with jpm.
I made a release (https://github.com/kkapsner/CanvasBlocker/releases/tag/0.2.2.1-OtherRelease) based on CFX which seems to work... please test.
Works!
@kkapsner: Yes baby! It works fully! Thanks for the quick fix! :+1: :)
You're welcome.
@kkapsner Does https://github.com/kkapsner/CanvasBlocker/tree/0.2.2.2-OtherRelease need a PM/SM version, due to #69? Or is that irrelevant?
Also, I hope the work being done on #53, #67, & #68 garners a PM/SM version, also.…
Thanks for all the extra work you do for us!
No - this version should work with Gecko 28 (not quite sure which is the lowest Gecko version it works with).
To be honest, I do not plan to create a new version for PM/SM. The last changes are made in the e10s version of the addon (version 0.2.2 versus version 0.3.0). But if someone voluntiers to backport the changes (which will require some work by hand) I'm happy to create a version 0.2.3-OtherRelese.
At the moment my focus is on creating verion 0.3.1 in my spare time, which is not too much.
AFAIK, the upcoming PM α (in progress) should support E10S out-of-the-box, so CanvasBlocker shouldn't need a _separate_ release for it anymore, just that additional section in the but someone from @MoonchildProductions, maybe Moonchild himself (@wolfbeast here on GitHub), would be best to say so officially.install.rdf, updated appropriately,
I'm really looking forward to trying out release 0.3+, especially now that fixes for #53 & #64 have now landed.
Responding as-requested:
We don't and won't be employing e10s. If your extension requires this, then it won't be compatible.
Additionally, SDK extensions are not going to be supported at all in the new milestone because there won't be a matching Mozilla Jetpack/SDK abstraction library available that matches our browser code. So I'm afraid this particular extension's compatibility will simply cease.
@wolfbeast that's sad to hear.
@kkapsner Maybe so, but it's just not something we can create and maintain. Additionally, our canvas.poisondata would make this particular extension unnecessary anyway so it's not a big loss.
I can understand that.
I do not know if your canvas.poisondata offers the same functionality since I have not looked at it... but maybe your user will point at missing parts.