Here's the problem. I get a message that pops up that says, "one or more extensions cannot be verified and have been disabled". I know a temporary fix to get these apps working again but the apps always break after so much time. What I do is go in my extensions for my Firefox profile (which is a JSON file) and I use Wordpad to change all the instances of appDisabled": true to appDisabled": false. I also change all the instances of signedState":-1 to signedState":2. The problem is that it keeps changing the false back to true and the 2's back to -1's. I am using Firefox version 56.0.2. Is there any permanent fix that can keep these changes under the current version that I am using? I am getting sick and tired of having to make these changes every day. Also, a couple of key add-ons that I use which are Classic Theme Restorer and unblock Origin keep getting disabling from this issue. I value these add-ons and I would love it if you knew any command prompt that I could put into Wordpad that would make Firefox stop trying to verify add-ons or whatever it does that causes Firefox to disable the add-ons. I welcome any other fix as well. I do want to keep my current version of Firefox and I know the Greasemonkey I use wouldn't work on later versions.
I already tried using Wordpad to change all instances of appDisabled": true to false and signedState":-1 to 2. It would work for a while and then everything reverted back to how it was.
...
appDisabled":true
...
signedState":-1
When appDisabled is true and signedState switches to -1, I get the message saying, "one or more extensions cannot be verified." It also disables the incompatible apps.
Related
Long story short:
I tried to create/edit GitHub Gists with
Firefox 67.0 on Windows 10
Firefox 67.0 on Linux Fedora
Add-ons: NoScript, Ghostery, LastPass
Tried with NoScript and Ghostery disabled and also with NoScript in "all shields down" mode and also with Firefox in "safe mode".
Problems:
Creation of a Gist is arbitrary. More often than not, the two buttons "create public gist" and "create secret gist" just stay disabled and the editor widget is "dead".
Occasionally, creation works, the editor widget goes lives and displays line numbers and the editor buttons become active. But it happens annoyingly rarely.
Editing a Gist is arbitrary. Again, it sometimes works but currently I just get blank editor widgets that have no cursor.
Anyone else who has these problems? It may be a temporary hiccup, or maybe there is some JavaScript that Firefox doesn't like. However, a web search brings up nothing - I can't believe I am the only one stuck with this this.
My earlier testing fails completely. I was sure I had tested in safe mode with no change in result.
However I retested with the latest Firefox update (FF 67 on Linux) and found out that it is the LastPass plugin which is the root of the problem. I would not have suspected that.
Disable that plugin, leaving all the others active and Gist creation and Gist editing work.
Enable that plugin and Gist creation and Gist editing work once after a Firefox restart. But after that, you get the unresponsive text entry widget.
Similarly, running Firefox in safe mode with all plugins disabled also fixes the "problem".
And of course, if you do this using Konqueror instead of Firefox, creation/editing work too.
I am trying to use WatiN to do some screen scraping type of work. It runs on our site on a scheduler. I have no need to see the UI, I just need it to do the work. I can navigate the sites with no issue , but when trying to downlaod the files I have 2 problems.
Using IE 11 when it comes time to download , I get stuck on the open/save dialog that pops up. I have tried and tried and tried everything to have IE 11 auto download files, but to no avail. I edited the registry, and tried every option in the security tab, but no luck. I tried using SendKey.Sendwait("{TAB}"), to mimic what would need to be pressed , but I get "access denied" I think the "ui" is locked.
so I tried Firefox, firefox is easy to configure "automatic downlaods" .... but
FireFox wont even connect, I get: No connection could be made because the target machine actively refused it 127.0.0.1:9997 I installed the appropriate jjsh addon and install it globally for all users from the command line, but still no luck.
Any suggestions on how to disable that yellow bar that IE 11 puts at the bottom of the screen to annoy you , or what I might try with firefox? I believe configuring IE 8 to disable the yellow dialog bar is possible, but I am on a windows 8 machine , so I'm stuck with IE 11, or possibly 10.
You can keep trying to find a solution but that solution will probably break in a next release of IE (based on previous experience) to be able to finally solve and be future proof (if there's such a thing in development....) I would suggest to navigate to the page that has the link and get the HREF portion of it and once you have that link just do the download using other ways, like the following:
(this is just pure C#, not watin)
string downloadURL = "http://example.com/retrievePDF.jsp?id=XXXXX";
client.DownloadFile(downloadURL, #"C:\temp\" + fName + ".pdf");
you should replace the downloadURL with the value on the HREF of your download link and you will be able to find the file where you specify it.
It worked until today, no code got changed
So if I do something like
page.find('#edit-user').native.send_keys(:tab, :tab) it's not working (it's highlighting the element #edit-user but not moving forward) specifically for the tab key, it's working correctly for :space or :enter.
It was working previously, it's a small possibility that it's related to some settings change for the Chrome browser but not sure exactly how and why
We are having this problem in Chrome as well, and it all started with Chrome update 44.
I tried using "\t", :tab, :return, :enter, and :escape to remove focus from a text input (symbols found here), but none of them are working in the most recent version of Chrome.
I know you mentioned you are not looking for solutions other than tab, but short of rolling back your browser version and disabling updates, or waiting for the possibility of a fix from Google itself, you will have to change the scripts being executed.
We found that this has worked well so far:
driver.execute_script("document.activeElement.blur()")
If the desired behavior in your case is to shift focus two fields forward, then you might consider another Javascript solution that looks something like what is discussed in this thread:
simulate the tab key function in javascript
Of course, this probably isn't the best long term solution, as even some very quick Googling shows that sending a tab key to switch focus has been recommended tons of times to people using WebDriver. Because of this, I'm keeping my fingers crossed there will be another Chrome update to revert the behavior.
Our continuous integration process uses Selenium, and twice in the last few months it has been knocked out of action thanks to firefox updating itself (either on developer machines or the CI server).
We have therefore installed the previous firefox version alongside the later one (this time in a directory called firefox-16), until Selenium catches up.
The problem is, the app.update.auto setting (in about:config) is set to true by default - meaning that sooner or later it will update itself to 17 and selenium will break. We therefore installed an all-no-update.js file in the /usr/lib/firefox-16/defaults/pref folder containing
user_pref("app.update.auto", false);
which (according to MDN) should override any other values. Unfortunately it doesn't work - the about:config page still shows auto-update as app.update.auto as true. This MDN page says:
All Mozilla-based applications read (application directory)/defaults/preferences/*.js
but unfortunately that doesn't work either - the value stays unchanged.
I've trawled the Bugzilla database but can't find anything relevant (other than the fact that an all.js file gets deleted by an upgrade so be sure to use all-*.js file).
Does anyone know enough about the workings of Mozilla Firefox to tell me how to set this preference value? (please don't say "click on the about:config page" - it needs to be automatically to ensure the build is repeatable and stable).
Thanks, James
Edit:
Sorry if the above isn't clear: I can create default preferences, for newly created profiles, just fine. But as users already have a profile this won't have any effect. I could possibly create a new profile on every machine, for every user, that has this setting disabled - but it is a lot of overhead. Sysadmins all over the world must be using this functionality somehow, surely: a way to override a given preference with a centrally-set one?
The most likely reason is using user_pref() function - as the name already says, this one is reserved for user's preferences (in user's profile), default preferences should use pref() instead.
You also have to consider that whatever you put into this directory are default preferences, they can be overridden in the browser profile (in the file prefs.js there). If you aren't using a clean profile the preference can already be set there and the default won't have any effect then.
For reference: A brief guide to Mozilla preferences
From MDN: Enterprise Deployment (Configuration)
Some config items require lockPref to be set, such as app.update.enabled. It will not work if it set with just pref.
Suspect this may apply to app.update.auto as well. Although I can find no obvious (i.e. named update) configuration option in about:config that is specific to any given add-on. So I don't even know if the per-add-on setting is a pref?
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!