I want to create a straightforward extension for Firefox.
User hovers over some word on any page
Pull the dictionary definition of that word from a file inside the extension
Display it while still hovered
I am new to Firefox add-ons and WebExtensions, so here's what I'm wondering:
I want the dictionary file(s) used by the extension to be local, instead of referring to some online website each time.
Any given user might be interested in a different part of the entire dictionary (it contains entries in different languages, users might only want their own 1 or 2 languages) so I want to avoid forcing every user to download the entire dictionary base.
The way I have seen similar add-ons handle that before Firefox 5.* is that they offer the search-and-display add-on separately from the dictionary files which are each available as add-ons in their own right, only actually doing stuff if you have the master add-on installed.
However, none of those examples seem to have been updated for the WebExtensions API and do not support more recent versions of Firefox.
I have also been unable to find how to communicate between web extensions so far.
My question being, how can I share information between 2 or more coorperating extensions to achieve what I described.
And actually, if this seems really stupid for some reason I'm unaware of, do point out any more reasonable alternatives that allow me to handle the dictionary files separately from the main extension.
Possibly related questions I found:
Communicating between 2 Firefox Add-Ons (Cross-Extension Communication)
This one is from 2010 however, thus out of date as far as I could tell.
Mozilla Addon Development - Communicating between windows with different domains
Kind of a similar situation, but they want to pull the definitions from an online source, rather than a local one.
The closest thing I found on the Mozilla browser extension website is communicating between add-on and some native applications, not quite what I need I think.
Communicating between add-ons is a normal part of the functionality of runtime.sendMessage(), runtime.connect(), runtime.onMessage, and runtime.onConnect.
Both runtime.sendMessage() and runtime.connect() have as their optional first parameter:
extensionId
For runtime.sendMessage(), this is:
string. The ID of the extension to send the message to. Include this to send the message to a different extension. If the intended recipient has set an ID explicitly using the applications key in manifest.json, then extensionId should have that value. Otherwise it should have the ID that was generated for the intended recipient.
If extensionId is omitted, the message will be sent to your own extension.
For runtime.connect(), this is:
string. The ID of the extension to connect to. If the target has set an ID explicitly using the applications key in manifest.json, then extensionId should have that value. Otherwise it should be have the ID that was generated for the target.
Both runtime.onMessage, and runtime.onConnect provide a sender property or parameter, either with the message, or as part of the port. This parameter/property is a runtime.MessageSender which includes an id property which is:
id
string. The ID of the extension that sent the message, if the message was sent by an extension. If the sender set an ID explicitly using the applications key in manifest.json, then id will have this value. Otherwise it will have the ID that was generated for the sender.
Note that in Firefox, before version 54, this value was the extension's internal ID (that is, the UUID that appears in the extension's URL).
Related
I'm using James Montemagno's Plugin.InAppBilling library for Xamarin to do iOS and Android in-app subscriptions. It has worked mostly correctly so far, except that once in a while, on iOS only, InAppBillingPurchase.PurchaseToken comes back null from calls to PurchaseAsync and GetPurchasesAsync.
For example, in my Restore Purchases logic, I have code similar to this:
var purchases = await CrossInAppBilling.Current.GetPurchasesAsync(ItemType.Subscription);
// Sometimes we receive purchases with no PurchaseToken.
// Can't verify the purchase without a token.
var verifiable = purchases.Where(p => !string.IsNullOrWhiteSpace(p.PurchaseToken));
At this point, verifiable sometimes has a different count (0) than purchases (1).
So far, this has seemed to happen when the user purchased using either store credit or a gift card, and only on iOS.
Also, I'm not sure if this bears on the problem, but I am not using the overloads of PurchaseAsync and GetPurchasesAsync which take IInAppBillingVerifyPurchase, because I use server-side verification exclusively (no client-side verification). My workflow is to make the purchase, add the resulting InAppPurchase object to a queue for processing, and then send it to our server as a separate step, for validation and association with the user's account. However, if this is not a valid workflow or if it is known that sometimes PurchaseToken data will be available via IInAppBillingVerifyPurchase.VerifyPurchase but not attached to the InAppBillingPurchase objects returned from the methods above, I would certainly like to know about that. (For what it's worth, I've read the documentation and don't see anything that suggests this.)
Thanks in advance for any help.
Okay, I think I've learned enough to provide useful information for anyone else dealing with this issue.
First, I've figured out what Apple means by "iOS 6 style" and "iOS 7 style" receipts. These do not refer to the version of iOS that creates the receipts. (My up-to-date iOS 12 device still can and does generate "iOS 6 style" receipts.) Instead, these refer to two different receipt formats that were introduced in the respective iOS versions.
iOS 6 style receipts come from SKPaymentTransaction.transactionReceipt and contain information about one specific transaction. This field is now deprecated by Apple.
iOS 7 style receipts come from the app bundle, via the location named in NSBundle.mainBundle.appStoreReceiptUrl. These receipts contain a full manifest of all purchases ever made by the user. The receipts don't expire either -- you can always send them to Apple for validation (though, obviously, individual transactions contained within might show as expired in the response). These are the receipts you should prefer.
The reason this is important is that if you're using the Plugin.InAppBilling library, the InAppBillingPurchase object you get from calling something like PurchaseAsync contains the deprecated iOS 6 style receipt in its PurchaseToken field.
I'm still not sure why it is sometimes present and sometimes null, but seeing as the underlying source of the data is deprecated, it's probably safe to assume that this can and will happen. Therefore, it probably makes sense to cut over to the iOS 7 style receipts as soon as possible.
Note that when you call PurchaseAsync, if you specify an implementation of IInAppBillingVerifyPurchase, your IInAppBillingVerifyPurchase.VerifyPurchase method will receive the newer iOS7 receipt instead. However, the InAppBillingPurchase object returned by PurchaseAsync still gets an iOS 6 style receipt (if it gets anything at all).
Personally, I like the InAppBillingPurchase object itself. It has useful information packed into a convenient package. Since I want to keep the serialized InAppBillingPurchase objects in a queue so that I can retry validation if there are problems with our servers, connectivity, etc, what I'm doing is immediately replacing the PurchaseToken property with the iOS 7 style receipt that I manually retrieve from the bundle.
If you do this, be sure that your code handles the slightly different formats of the iOS 6 and iOS 7 receipts properly. (Our earlier attempts had some errors stemming from not properly understanding what these terms meant.)
I hope this is useful to someone out there. Good luck!
Trying to detect the first install event from branch.io link (succesfully implement link creating and sharing). I am using Unity branch sdk. The feature i try to create:
user_1 creates and share link to user_2.
When user_2 opens the link and install app i need to reward both of them (with inner in-game coins)
So i succesfully implement the 1. but I cant understand how to detect is user_2 installs the app or simply open it. All data that comes from branch.io UniversalObject callback doesn't contain information that i need.
Which the correct way to detect the install from code?
Alex from Branch here.
The callback parameter you need is +is_first_session. This is one of the parameters returned when the Branch session is initiated each time your app opens (you can find all all these parameters here). If this returns true, then that device has just installed the app (instead of opening it).
However, note that when these parameters are returned, it's impossible to immediately determine if the user is new (what you want), the device is new (not what you want, since the reward could be given twice if the user has installed on multiple devices), or neither (the user deleted the app and reinstalled on the same device). You would probably want to hold off on actually awarding the referral points until after the user has logged in with some sort of unique ID.
Branch also has a built-in feature for tracking referral points that might be useful. That lets you configure all the rules using the dashboard UI instead of needing to do it programmatically inside your app.
I have subclassed RazorViewEngine so I can check for Request.Browser.IsMobileDevice and add a special mobile identifier to the view file name for it to grab. However I can't access the Request object. What should I do?
You can use either the HttpContext.Current.Request or Context.Request. Although understand how that IsMobileDevice works. It uses a browser file which contains a list of known user agents. As soon as a new device is built, that list is outdated, but in some cases may still identify the device to be mobile correctly. The recommended way is to use 51Degrees or to connect to the services it encompasses directly.
Extension Link: https://www.dephormation.org.uk/?page=81
This plugin is great. It has one problem though, on pages that use AJAX to make http requests, it switches the user agent for each request and confuses many ajax applications.
What I want to do is figure out where the preferences for this plugin are saved. Particularly, where all the User-Agent Strings that are currently being used are located. I would like to do this so that I could edit these settings outside of firefox before I open the browser so as to "hot swap" one user agent string for each browsing session at a time. I have looked through all kinds of .sqlite databases in my firefox profile but still haven't found the information.
I am using Watir-Webdriver with ruby to application test.
As Mr Palant said... simply changing general.useragent.override would achieve what you want.
Type about:config in the address bar, accept the warning, and filter on useragent and you'll see the setting.
I gather (but haven't tested) this preference may not affect the user agent presented to client side Javascript code. So if your Ajax code references navigator.useragent you might find the real user agent is returned despite your override setting.
Pete (author of SecretAgent).
www.secretagent.org.uk
PS See also
https://developer.mozilla.org/en/Document_Object_Model_%28DOM%29/window.navigator.userAgent
You don't need an add-on for that - changing general.useragent.override preference (create it if not present yet) is enough to set a different user agent string. In Firefox you can do it under about:config, when Firefox isn't running you can add this preference to the file prefs.js in the Firefox profile.
I have written a Firefox extension that catches when a particular URL is entered and does some stuff. My main app launches Firefox with this URL. The URL contains sensitive information so I don't want it being stored in the history.
I'm concerned about the case where the extension is not installed. If its not installed and Firefox gets launched with the sensitive URL, it will get stored in history and there's nothing I can do about it. So my idea is to use a bookmarklet.
I will launch Firefox with "javascript:window.location.href='pleaseinstallthisplugin.html'; sensitiveinfo='blahblah'".
If the extension is not installed they will get redirected to a page that tells them to install it and the sensitive info won't get stored in the history. If the extension IS installed it will grab the information in the sensitiveinfo variable and do its thing.
My question is, can the bookmarklet call a method in the extension to pass the sensitive info (and if so, how) or can the extension catch when javascript is being called in the bookmarklet?
How can a bookmarklet and Firefox extension communicate?
p.s. The alternative means of getting around this situation would be for my main app to launch Firefox and communicate with the extension using sockets but I am loath to do that because I've run into too many issues over the years with users with crazy firewalls blocking socket communication. I'd like to do everything without sockets if possible.
As far as I know, bookmarklets can never access chrome files (extensions).
Bookmarklets are executed in the scope of the current document, which is almost always a content document. However, if you are passing it in via the command line, it seems to work:
/Applications/Namoroka.app/Contents/MacOS/firefox-bin javascript:alert\(Components\)
Accessing Components would throw if it was not allowed, but the alert displays the proper object.
You could use unsafeWindow to inject a global. You can add a mere property so that your bookmarklet only needs to detect whether the global is defined or not, but you should know that, as far as I know, there is no way to prohibit sites in a non-bookmarklet context from also sniffing for this same global (since it may be a privacy concern to some that sites can detect whether they are using the extension). I have confirmed in my own add-on which injects a global in a manner similar to that below that it does work in a bookmarklet as well as regular site context.
If you register an nsIObserver, e.g., where content-document-global-created is the topic, and then unwrap the subject, you can inject your global (see this if you need to inject something more sophisticated like an object with methods).
Here is some (untested) code which should do the trick:
var observerService = Cc['#mozilla.org/observer-service;1'].getService(Ci.nsIObserverService);
observerService.addObserver({observe: function (subject, topic, data) {
var unsafeWindow = XPCNativeWrapper.unwrap(subject);
unsafeWindow.myGlobal = true;
}}, 'content-document-global-created', false);
See this and this if you want an apparently easier way in an SDK add-on (not sure whether SDK postMessage communication would work as an alternative but with the apparently same concern that this would be exposed to non-bookmarklet contexts (i.e., regular websites) as well).