I'm developing a Firefox add-on. Part of the extension requires evaluating code in the context of a particular content window.
I found tab_utils.getTabContentWindow, which returns the ContentWindow of the given tab. The properties of this object are the properties of the webpage's window object.
From my testing it seems like accessing properties, calling ContentWindow functions, etc. all happens in the context of the webpage rather than the add-on. However, I'm not well-versed enough to know if this is sufficient for security, and the Mozilla docs don't make this clear.
Is it safe to access ContentWindow properties, use functions defined on ContentWindow, and access their results?
Good q, answer is no. As with e10s coming out next version it will be a separate process. So it will use a shim. And that shim will be going away 6 months after e10s (process tabs) release.
So you're going to want to use the sdk contentScript. Looks like you're using sdk.
Related
I'm developing an extension and I'm a bit stuck about the communication between the web-app, the content-script of the extension, and the communication between the content-script and the background-script. It seems to be that HTML5 Messaging API is to be used, but how to do that in a precise context is not only hard to understand and implement, but also confusing due to differences of approach in Browsers (which seemingly support the same API).
For example, Firefox doesn't recognise the externally_connectable in manifest.json, which is where one assigns permissions for the hosts where requests originate from. So how does Firefox expect you the developer to assign the permissions? I assume it expects you do that within the content-script?
Particularly, I'm confused about what is the best way to exchange data between the app and the content/background script. Is the best way postMessage / addListener methods and do they work in all contexts; or as someone mentioned: window.dispatchEvent should be preferred?
All guides relevant to the point above are appreciated.
Messages coming from outside the extension is not something I have experience with (and I'm not sure that's what you mean).
You should make sure you thoroughly understand the chrome extensions overview which is definitely required reading.
re Window.dispatch and using other APIs, my suggestion is stick to the chrome.xxx APIs unless there's something they can't do.
There are 3 scopes potentially in your extension that can only communicate by messaging but the messaging is simple to implement and actually can lead to good designs.
Content scripts are the key to interacting with the page itself but their scope isn't the same as the page, the js is isolated but they can access the DOM of course.
Content scripts can be loaded when every page loads or just some pages by including them in the manifest. Or powerfully, they can be injected by the background page or the popup - so if you're intention is to control from the popup, you can use programmatic injection - a useful pattern is that the popup (or background) can launch a url in a tab, inject jquery (any version because it's isolated), then inject the content script, the content script can then use $(document).ready() to wait for the page to be loaded (don't have to use jQuery but the fact that you can without caring whether the page has jQuery or not, or what version it might have) is useful.
If you already knew this much, you might not be as confused as you think :)
I don't know when this started happening or if things have changed but the _host_Info param is not being passed by the framework to my Excel Add-In in Excel Online.
It passes an empty "et=" parameter which is OK in this case since I'm in dev mode. The Excel desktop client is still passing it.
This is required by my add-ins to switch functionality between Excel Online and Excel for Windows.
I've checked the docs and can't find that anything has changed.
To append to Sudhi's answer: with the official API coming as per the link in Sudhi's answer, we've gone ahead and also added a "shim" for the API in the OfficeJsHelpers library.
The shim still uses the workaround code that Sudhi mentions -- window.sessionStorage['hostInfoValue'] -- but it wraps it in an API very similar to what is coming in the official Office.js. Once the official API is available, we'll switch the shim code to make use of that instead. The beauty of this approach is that if you use OfficeJsHelpers via an NPM package, all you have to do is update your package dependency, and you'll suddenly go from an unofficial and potentially-fragile workaround to an API that relies on 100% officially-exposed properties -- all without changing your own code! Likewise, if at that time you decide to switch back to using the official Office.js version, the similarity of the APIs (essentially just namespace differences) should make it trivial to switch over the implementations.
The helper APIs are OfficeHelpers.Utilities.host (which will return WORD, EXCEL, etc.) and OfficeHelpers.Utilities.platform (which will return IOS, PC, OFFICE_ONLINE, or MAC). The constants are defined in OfficeHelpers.HostType and OfficeHelpers.PlatformType.
You can find the NPM package at https://www.npmjs.com/package/#microsoft/office-js-helpers, and either install it via NPM, or use a CDN like Unpkg to quickly try it out: https://unpkg.com/#microsoft/office-js-helpers#0.4.2/dist/office.helpers.min.js
console.log(OfficeHelpers.Utilities.host);
console.log(OfficeHelpers.Utilities.platform);
if (OfficeHelpers.Utilities.platform === OfficeHelpers.PlatformType.OFFICE_ONLINE) {
console.log("Yep, I'm on the web client");
}
I hope you find the above helpful as an interim measure, and we'll be sure to update this StackOverflow thread (and the OfficeJsHelpers code) once the official API is released.
Jim and others who may be affected by this change: it is unfortunate that an unrelated change meant to improve the add-in experience caused the query string parameter in online platform to be removed. Note that URL query parameters and session storage settings are used to launch and setup the add-in environment and are not meant for developer consumption. However, we understand the importance of this to the developers as described in this thread.
Hence, we are adding formal APIs to make this information available. Please see the specs that describes upcoming APIs: https://github.com/OfficeDev/office-js-docs/tree/ContextAdditions_OpenSpec
Until the APIs become available (should be very soon), you could use the following temporary workaround. The same query host_info_ parameter value is available in the following variable: window.sessionStorage.hostInfoValue. Please note that this should be considered a temporary measure and you should switch to using the formal API as soon as they are made available. I'll update the this thread when the API is released, which should be available for all supported Office versions.
If you have any comments, please leave your comments on the specs directly in Github specification branch using the links provided.
UPDATE:
Please see my answer above, instead (https://stackoverflow.com/a/40963500/678505), as the scenario is now possible.
[Old response:]
Jim, could you describe your scenario more? Why is it that you need to distinguish between Online and Desktop?
For the disappearance of host_info_: you won't find it in the docs, because host_info_ was never in the docs. Anything not documented is an internal API, which might change as needed by the internal workings of Office.js. We take back-compat very seriously, but only for actual official documented APIs.
Without an API, there's not much you can do to tell the two apart (or rather, not without relying on other bits of internal workings which might also change over time). We've discussed this internally before, but found it surprisingly difficult to point to a particular scenario where the platform information was necessary and legitimate ("legitimate" in the sense that if you're using platform information to check whether an API is available, for example, that's precisely what we don't want you to do; we want you to use Office.context.requirements.isSetSupported instead).
If you can share your scenario details, I might be able to advise an alternate way of determining whatever you need, or have a solid scenario to bring back to the team.
Accessing controls values, what is the recommended way to use ?
document.getElementById(...) or XSP.getElementById(...)
The XSP object acts a "wrapper" and would hide implementation details (browser incompatibilities, etc.) for you, therefore I would prefer the use of XSP.getElementById(...):
The XSPClientDojo library defines a global XSP object which exposes
some JavaScript functions to the XPages runtime. As its name suggests,
XSPClientDojo utilizes the Dojo JavaScript library, however other
implementations may be developed in the future (for example, when
supporting handheld devices).
document.getElementById(...) places the reliance on browser implementation. XSP.getElementById(...) places the reliance on the IBM Dojo extension and IBM support.
The same rules hold for any of the XSP.... methods. If browsers changes should ever affect it, IBM code will be updated and as long as your server is on the current release and fix packs you will not need to make changes to your application. So as with relying on any framework, it comes down to whether you are willing to keep the framework up to date to leverage the extra layer of abstraction.
I've found this nice article about the "injected Way", but the author never finished it :
http://hightechstartups.blogspot.ch/2012/05/different-way-of-developing-browser.html
I would like a bare bone cross browser extension, without any 3rd party extensions or framework (to be as light as possible and not dependant on a 3rd party) that would load Jquery and a JS from a distant server and the ability to load it before or after the page is fully loaded.
I've read a lot of topics about the subject, but since IE10, Chrome 26 and FF20 are out with their new cross-link limitations, i was wondering if somebody had ressources, source code or tutorial about the following requirements :
I need :
Cross browser extension supporting (IE 8+ or 9+ worse case, Chrome
26+, FF20+, Safari)
Ability to inject a single JS hosted on another server. Inserts a script tag that references a javascript file in the head of the HTML
page and then be executed
Not be dependant on a third party extension (greasmonkey) or framework (Kango, Crossrider)
Ability to load before or after the page is fully loaded
This method allows me to customise the browser extension depending on the user's location and it also avoid having updates as the JS is updated on each page refresh.
I'm aware of the downsides, but i would like to achieve this.
I'm aware of cross browser framework like Kango or crossrider, but both don't fit me needs.
The closest example i could find is this How can I run a <script> tag that I just inserted dynamically from a BHO
but it only covers IE and as i got very little Csharp experience, i would like to see a full example to understand it properly and learn from example.
I would LOVE to have a few examples, even if it's not cross-browser (IE being the worst part for me).
Thanks a lot for your support !
Update1:
About Kango and Crossrider, Kango is 2000$ if you want to use IE and for Crossrider you're required to be distributed and monetized by them.
I've managed to code for IE and Chrome, but i was looking for an "elegant" way and figured it was the best place to ask given the level of knowledge of people on this site.
For the installer i currently use NSIS, but i'll test Wix too.
Finally i guess the only way for me would be to learn C++ and .net to get it to work with IE, but if anyone could provide more source code it would be great to test speed and compatibility and discuss here what's the best solution.
Why do Kango or Crossrider not fit your needs? Both frameworks allow you to manipulate the page's DOM (which is what you want):
Kango: Adding content script
Crossrider: documentation, example code
If you want to code your own solution, take a look at the relevant documentation:
Content scripts (Chrome)
The Page mod Jetpack API (Firefox)
Injected scrips (Safari)
Injected scripts (Opera)
Internet Explorer does not natively support extensions. It took me about 80 hours to create a stable and reliable IE extension which supports cross-site AJAX, a (preference) storage method and injection of scripts as early as possible in any frames based on its URL. I developed and tested the extension with Visual Express 2010 on Windows XP and Windows 7, for IE 8-10 (the extension might work on IE6/7, but I decided to not support these ancient and rarely used browsers).
First, I wrote an extension in C# based on LiveReloadIEExtension (a sample IE extension, which in turn is based on this Stack Overflow answer - see also this blog post). It was functional, but it required .NET 4, lacked support of frames, and it's relatively slow.
So, I decided to write an IE extension from scratch in C++. A good starting point is available at http://www.wischik.com/lu/programmer/bho.html: Sample code for C++ BHO, which changes the document's background based on key/mouse events. I've also learned a lot by looking at other code samples on CodeProject, topics on the MSDN forums, questions and answers on Stack Overflow, lots of other blogs, and the MSDN documentation:
DWebBrowserEvents2 interface lists several events which you use to find an appropriate injection point.
Scripting Object Interfaces (MSHTML) lists even more interfaces. You'll be mainly interested in the iHTMLDocument, iHTMLDocument2, ... interfaces.
After creating the IE extension, you want to deploy it of course. I used Wix toolset to create a MSI.
I want to develop an application that will visualize the recommendations of Google instant. It is for a course project and for now, I don't know much about web programming tools. What I wonder is that is it possible to retrieve that data from another web page. If you think it is possible and it is possible with which platform, could you please guide me to the correct direction?
Without more information on what you're actually trying to do, it's difficult to give a proper answer. From what I can understand, you just want a list of the auto-completed items from a Google search, to manipulate however you like?
In which case, using the highest-rated answer from here, you can use http://suggestqueries.google.com/complete/search?client=firefox&q=YOURQUERY to give you a JSON object which you can then manipulate to get the auto-complete results. The client= part is needed, but I haven't looked at various options you can put in there.
Personally, I've never used JSON before, so can't give you any help on how to go about parsing it, but you can find more information about it on the JSON website, and w3 website.
Will need to act like javascript or run a javascript engine OR a browser add on and communication with that add on.
What happens as you type is a javascript function is called. So you need to call this function in your own or mimic what it does. I guess it calls a web service/ web page form programamtically (ajax) with what you have typed. The server responds with the suggestions. Not very difficult as long as Google does not deny you if it realizes your not a browser. i think they like only 100 free API calls but you can google google about that.
Http Components in java will help calling the serice, with cookeis etc. You should use the dev tools on firefox to see what happens under the hood when you type in the google search bar and see the code.