My OperaYou need to be logged in to post in the forums. If you do not have an account, please sign up first.
Buggy example in the "messages" article
I am hugely disappointed with the article which was supposed to explain how messaging works - in fact, the key problem for the extension I'm working on is to be able to communicate between background script, user scripts and the popup. I haven't looked much into other examples and mostly analyzed "example 3" - and I found two bugs in it (one of them may or may not be a browser issue). There's also quite a lack of documentation regarding the MessageChannel and MessagePort classes.I tried a simple modification to the example 3, so that it not just logs the communications, but also does something more - displays the title of the page in the popup - http://code.dominykas.com/opera-extensions/message_example3/message_example3_modified.oex
Bug 1. Since "port" is global, switching between tabs does not reflect in the popup
Bug 2. Can't click on the popup link more than once
Full details and steps to reproduce the bugs: http://code.dominykas.com/opera-extensions/message_example3/readme.txt
I think I already have a solution for this, but want to do some more testing and play around with it, before I publish.
OK, I think I now have an example of messaging that works (for now) - http://code.dominykas.com/opera-extensions/title_in_popup.oex
I also wrote an explanatory blog article - http://www.dominykas.com/2010/11/opera-extensions-messaging-example.html
I also wrote an explanatory blog article - http://www.dominykas.com/2010/11/opera-extensions-messaging-example.html
4. November 2010, 22:09:50 (edited)
I'm also checking for the connected window's type through e.origin ("widget://") and set a global var "popup" that's updated each time aforementioned window type connects. However I do not (yet) explicitly use ports as I'm guessing each window/tab is assigned a port by default and WINDOW.postMessage() merely retrieves the associated port and calls PORT.postMessage().
EDIT:
Actually looks like I'm doing what I described above, except I have the background window as a message proxy. It works, though better efficiency is obtained through direct (port) communication.
I just tried, from the popup, calling postMessage() on the focused tab (whose reference I got from the background script) which doesn't seem to work, for whom it may concern. :\
EDIT:
Actually looks like I'm doing what I described above, except I have the background window as a message proxy. It works, though better efficiency is obtained through direct (port) communication.
I just tried, from the popup, calling postMessage() on the focused tab (whose reference I got from the background script) which doesn't seem to work, for whom it may concern. :\
eternal1, I don't think you're allowed to pass the reference of the tab into popup - that would break the whole principle of isolating it from the pages and the background.
As for having a proxy... I think it should be possible to build a smart proxy so that it's easy enough to forward the messages, without actually inspecting each one of them - so yeah, I think you're right that this may be easier and simpler to understand, rather than the whole deal with MessageChannel.
As for having a proxy... I think it should be possible to build a smart proxy so that it's easy enough to forward the messages, without actually inspecting each one of them - so yeah, I think you're right that this may be easier and simpler to understand, rather than the whole deal with MessageChannel.
@dymonaz
I think don't think it breaks against any security principle, since a reference is just an integer number, and it's counterpart in lower level languages (like C for example) is the pointers. Pointers can be passed around between processes and kernels (and it's services), so one can send for example a message to a port by calling into the kernel (usually through a userland library function) passing it the pointer to that port and also a pointer to a message structure. Being able to *have* and *pass* a pointer does not mean the process can access the port directly manipulating it, that would cause an exception because the port is residing in the address space of another process, which is not mapped to the violating process, hence causing an exception and ending the life of the violating process.
So, references themselves in a browser script context need not be isolated (and aren't), but the content of what they refer to must be (between isolated contexts).
I can't see why WINDOW.postMessage() *could* be a security risk, assuming all other methods are inaccessible from a separate context. Now I have no idea have a javascript engine behaves from inside, but making WINDOW.postMessage() work would probably not be very pretty and a hack, resulting also in minor overhead.
I think don't think it breaks against any security principle, since a reference is just an integer number, and it's counterpart in lower level languages (like C for example) is the pointers. Pointers can be passed around between processes and kernels (and it's services), so one can send for example a message to a port by calling into the kernel (usually through a userland library function) passing it the pointer to that port and also a pointer to a message structure. Being able to *have* and *pass* a pointer does not mean the process can access the port directly manipulating it, that would cause an exception because the port is residing in the address space of another process, which is not mapped to the violating process, hence causing an exception and ending the life of the violating process.
So, references themselves in a browser script context need not be isolated (and aren't), but the content of what they refer to must be (between isolated contexts).
I can't see why WINDOW.postMessage() *could* be a security risk, assuming all other methods are inaccessible from a separate context. Now I have no idea have a javascript engine behaves from inside, but making WINDOW.postMessage() work would probably not be very pretty and a hack, resulting also in minor overhead.
eternal1, I'm not sure I agree with you. This should be answered by the Opera team. I have this question as "Are we allowed to pass objects using postMessage()" - it seems that it works, but the docs say only DOMString is allowed. I believe the intent is the same story as web workers API - you can only pass around strings, which essentially means that you're not allowed to pass a reference, hence no direct way of postMessage() back to some unrelated window.
If I'm not mistaken, you can also load any external URL in the popup window - it would be wrong to allow that external page to have access to the internals (even if just "pointers") of the browser (e.g. active tab, etc). Oh, and if you can't load an external URL into the popup window - you should be able to
If I'm not mistaken, you can also load any external URL in the popup window - it would be wrong to allow that external page to have access to the internals (even if just "pointers") of the browser (e.g. active tab, etc). Oh, and if you can't load an external URL into the popup window - you should be able to
5. November 2010, 18:43:05 (edited)
@dymonaz
Strings are objects too, and they are passed by reference, would be unnecessarily inefficient otherwise. When you on the other hand "pass strings" to ports through message port APIs, those APIs will copy the string and create an object on the recipient context that is then fired as an event of type "message". Why couldn't those APIs be able to clone those objects just as they do strings ?
Obviously possible methods defined (referenced) inside those objects would be invalid and off limit to the recipient and make no sense, but custom objects as solely containing properties (and no methods) no more of a security issue than are string objects. The only difference between a DOMString object and a custom object is that the latter is an object possibly containing any number of other DOMString objects.
Strings are objects too, and they are passed by reference, would be unnecessarily inefficient otherwise. When you on the other hand "pass strings" to ports through message port APIs, those APIs will copy the string and create an object on the recipient context that is then fired as an event of type "message". Why couldn't those APIs be able to clone those objects just as they do strings ?
Obviously possible methods defined (referenced) inside those objects would be invalid and off limit to the recipient and make no sense, but custom objects as solely containing properties (and no methods) no more of a security issue than are string objects. The only difference between a DOMString object and a custom object is that the latter is an object possibly containing any number of other DOMString objects.
Forums » Dev.Opera » Opera Extensions Development Discussions