I am working on a new version of a firefox extension, but after releasing it, and incrementing the em:version in install.rdf and update.rdf, when I click "Find updates" Firefox reports that "No updates were found." When I run it with debugging on, the output in the console is actually identical to what I see when I don't put the update live.
It starts with RDFItemUpdater:checkForUpdates with all of the parameters, and returns with Addon Update Ended and status: 8.
I verified with McCoy tool that the extension is signed, and has the same Id as the old one, etc. I'm not sure what else to try. Any advice would be appreciated. This is with Firefox 3 (and the extension is marked as compatible with it... that didn't change).
Make sure your update.rdf file is being served with an appropriate Content-Type, i.e. text/rdf, text/xml or application/xml+rdf
If you've only recently changed update.rdf, maybe it's cached. Load it in the browser then Shift-Refresh.
here are some nice tips that helped me: https://developer.mozilla.org/en/Extension_Versioning,_Update_and_Compatibility
but, auto update function will not work if extension is marked "experimental".
I'm having a similar issue, and think it's due to an invalid rdf file. Did you check that yours parsed with this tool? http://www.w3.org/RDF/Validator/
There are lots of things to mess up, one of which is installing an extension from AMO and expecting it to update when you change your update.rdf :)
I was having the same problem. In my update.rdf, I had a wildcard in my minVersion attribute:
minVersion="3.0.*"
Removing the wildcard fixed the status 8:
minVersion="3.0"
The update works now (console shows status 1). This was using Firefox 3.0.18.
My guess is that status 8 means there was a problem understanding the contents of the file (not necessarily an RDF parsing problem). If your minVersion doesn't have a wildcard, maybe there's an invalid character hiding somewhere.
Related
I am running Google Chrome Version 61.0.3163.100. I previously was running the Sense (Beta) extension version 0.9.4 until Google Chrome flagged it as malware in the extensions tab. The author of Sense has removed it from the Chrome store and it has been rolled into Kibana and renamed Console.
Problem is all the queries I wrote in the Sense console are not retrievable due to the extension being disabled. Previously, every time I opened the Sense (Beta) extension, all my previous queries would be saved and re-displayed each session. I would like to find the file location where Sense stored my queries for redisplay.
I am running Windows 10. I have tried locating my saved data by going to:
C:\Users\Admin\AppData\Local\Google\Chrome\User Data\Default\Extensions
There is nothing identifiable I can find that resembles my old data. Does anyone know where I can retrieve it?
Please download this zip file from my dropbox and follow the instructions to install it. Please run the file through some anti-virus to protect yourself. Thanks to this link to help me export chrome extension.
List item Download and unzip attachment
Go to chrome://extensions
Delete the current Sense plugin installed
Check developer mode and click on "Load unpacked extension..." and select the unzipped folder.
It seems like in the case of the Sense extension, its only persistent data was kept in localStorage (relevant source).
Whether data recovery will be easy depends heavily on when you last used the extension.
If you last used the extension before Chrome 61 (~ September 2017), then you are in luck: the localStorage database is stored in SQLite 3 format.
You need to find the corresponding chrome-extension_[some_id]_0.localstorage file under Local Storage in your profile; it's an SQLite database. The ID doesn't seem to be the same as the extension ID.
You can load it in various tools, including sqliteonline.com for an online browser.
If you need data since update to Chrome 61, you're in a much tougher situation. Chrome 61 switched to LevelDB for localStorage backend, and I couldn't easily extract the data from it.
See this question for subtleties involved. The database itself is located at Local Storage/leveldb in your profile.
It seems like Chrome does not delete older SQLite-formatted data, so you can recover at least data from early September.
FWIW, the ID of the extension appears to have been lhjgkmllcaadmopgmanpapmpjgmfcfig
You can copy your Chrome profile to your ChromiumPortable profile then your Sense extension will be enabled in Chromium with all your history.
Chrome profile
C:\Users\xxxx\AppData\Local\Google\Chrome\User Data\Default
Chromium Profile (rename existing profile to Default.bak)
C:\ChromiumPortable\Data\Chromium\UserData\Default
I had the same problem and the above fix got me my Sense history. I am using Chrome 63 and Chromium 65.
Update: Just updated to Chrome 79, this no longer allows me to load addon.
Just updated my Chrome to 69, It disabled my Sense (beta) addon with a "Malware" message, and I thought I lost all my data. The solution is pretty simple.
Go to chrome://flags/#extension-content-verification flag settings by setting as Enforce Strict, changing it to Bootstrap.
This let me load the extension, and all my saved queries were there.
To identify the extension you need to open chrome://extensions/ and check "Developer mode" (on the top right), then scroll down to the extension and you'll find the Extension's ID.
Folder under C:\Users\Admin\AppData\Local\Google\Chrome\User Data\Default\Extensions will be named with Extensions' IDs.
Just have installed new firefox developer edition and one of the feautures is checking the website in another browsers remotely. So I opened my website and typed in firefox's new command line "ios" to test it on safary, but got error TypeError: response is null .
Did somebody already tried? Any ideas how to make this work? Thanks
There is a list of connection issues here and you can submit a new issue here if it is not listed.
I am using the Valence addon (the thing that makes connecting to ios and chrome possible) everyday without any problem, but I always go via the WebIDE. I never tried using the ios command. I'm not sure how much this command was tested recently, it might just be broken.
You should try using the WebIDE (which you can find in the Tools/Web Developer menu).
Once opened, you can select "Safari on iOS" from the runtime menu.
More information about this can be found on MDN.
I've filed the following issue on the Github repo. Feel free to comment on the issue to add more info if needed.
I've just released 0.2.3 of the Valence (Developer Tools Adapter) add-on. Once you get this update, the ios command should work as expected. You can check your current version on the about:addons page.
If you continue to have trouble, please file a new issue.
When trying to restore a version of a document in my document based application, I get an error:
kCGErrorFailure: CGSDisplayID: App trying to enumerate [0 to CGSGetNumberOfDisplays()] instead of using CGSGetDisplayList(). Compensating...
kCGErrorFailure: Set a breakpoint # CGErrorBreakpoint() to catch errors as they are logged.
and the document remains unchanged. Also, when this happens, I get a message as soon as I start editing the document telling me:
The document [...] could not be autosaved. The file has been changed by another application.
I think these two problems may be related.
I don't know what to do or "check" because versions just works without any implementation needed; I'm actually confused, because Apple says that I just need to enable autosave in order to restore/revert using versions. Does anyone know what can be causing that error?
Thanks.
I've ran into all of your issues, causing me much pain.
I've gotten that error message regarding kCGErrorFailure... before as well when browsing versions. I've just ignored it mostly as it seems harmless to me. TextEdit seems to spit out this message as well. (Looks like an Apple bug)
For the "document remains unchanged", check here: Restoring from versions browser on OSX lion not working... ideas? (in short, your code for updating your document's UI is probably not being called for the document that is being reverted) (Looks undocumented to me)
For autosaving issues, check here: http://www.cocoabuilder.com/archive/cocoa/306217-how-to-implement-autosaving-browsing-versions-reverting-to-last-saved-in-lion.html (in short, use the file wrapper methods instead for reading and writing). (Looks like an Apple bug)
As well as returning YES to autosavesInPlace: your document needs to at least call updateChangeCount: passing NSChangeDone whenever it changes, so that it "knows" that there are changes to be autosaved.
Some of the webpages I visit have stubborn save file dialogs for executables. I would like to do one of the following using an extension:
Save the file by default and close the dialog box. I looked at http://kb.mozillazine.org/File_types_and_download_actions It doesn't really work for these files (the problem is described at: http://kb.mozillazine.org/File_types_and_download_actions under 'Unable to set automatic action. I verified the headers.)
I guess I can use browser.download.manager.closeWhenDone from https:// developer.mozilla.org/en/Download_Manager_preferences , if I figure out the first part :)
Suppress the download manager from showing any such dialogs altogether.
I found https:// developer.mozilla.org/en/nsIDownloadManager#addListener() and https:// developer.mozilla.org/en/Download_Manager_improvements_in_Firefox_3 that look promising. I don't really know how to extract the source URI for the transfer either. I'm curious if anyone has any existing examples for using these or if there's a better way to do this. Or if someone knows what part of Firefox's code I could poke, that would be useful too.
Thanks!
PS: Sorry,I had to break the hyper-links above with an unnecessary space after https:// - apparently I need 10 reputation to do that :)
FWIW, I managed to work around this - though my solution probably wont work for most others.
Fortunately I'm behind a proxy I control, so I just corrected the obnoxious headers (Content-Disposition and Content-Type) before they reached Firefox. These were forcing Firefox to open the File Save Dialog box despite my specified preference to 'Always save file of this type'. Furthermore, I set 'browser.download.manager.closeWhenDone' property to True. Works for me, and I cruise through such sites w.o being interrupted.
I have been developing an AJAX application using jQuery and Microsoft Seadragon technology.
I need to have access to the html5 canvas function toDataURL.
With Google Chrome, the same origin rule applies to this function which means that a page run locally (with the file:/// in the URL) failed to satisfy the same origin rule and an exception is thrown.
With Chrome 7, starting the application with --allow-file-access-from-files option, allows to call canvas.toDataURL() from local files.
However, it seems that starting the Chrome Beta 8 with the same option (--allow-file-access-from-files) does not allow the call canvas.toDataURL() on the local file.
Does Chrome gave up on the --allow-file-access-from-files option or it has just been disabled since it is a Beta release and not a full release?
Thanks!
Looking at the issues for this shows that the whole --allow-file-access-from-files thing was rushed.
"Firefox does it.."
"How can we do it?"
some time passes
"Here are the patches"
"Passes! On trunk wonder what happens in the next dev release"
"Ahhh it's broken" "Use the command line option" "ok"
"We shipped!"
"WTF guys? You broke all my stuff! Why didn't you tell us earlier?"
silence
On to your Problem
Indeed it seems that this is something special to the beta, I'm using Chrome 8.0.552.5 dev here and --allow-file-access-from-files works like expected, I've also tested this with Chromium 9.0.592.0 (66889) were it also works as expected.
I suspect there have been some changes on the dev branch. Unfortunately, finding something on chromium's issue tracker is nearly impossible.
Did you close all chrome instances before opening with the command line argument? You have to do that to make that parameter work.
To summarize all answers so far.
Before running chrome, make sure there are no chrome processes running.
Windows
-allow-file-access-from-files
(with one dash)
Linux
--allow-file-access-from-files
(with two dashes)
I've found a way around the issue using a JavaScript/Flash approach. If flash is compiled in the Local Only security sandbox, it has full access to local files. Using ExternalInterface, JavaScript can request a Flash Application to load a file, and Flash can pass the result back to JavaScript.
You can find my implementation here: https://code.google.com/p/flash-loader/
The trick that woked for me is that you have to give the absolute path of the file and not just file name in your HTML code. e.g file://... instead of direct name even though you are accessing the file in the same directory. It will work!