How To HOT! Download Video On Youtube With Chrome
Syed Kleiner
now craziest thing about it is that we do not see the same behaviour if Chrome is running as a regular, non-maximized window. If Chrome is running in a regular window we can move things on top of that just fine. Even if Chrome window is covering entire desktop there is no "ghosting". Windows move fine without leaving the trace. but as soon as we maximize Chrome window we start seeing "ghost" images of windows that used to be on top of Chrome.
Do yourself a favor and download the admx templates for chrome so you can manage it via gpo's. it's great, been using it for years and it would have solved your issue way faster than creating new shortcuts for chrome.
Well I took my own advice and this settings does not seem to be in the latest admx files. I've posted the question in google chrome forums, hopefully someone will advise soon and I'll post an update.
i opted for deploying Modified Shortcuts (one in desktop and one in Start Menu) and it has worked without any visible impact for two days now. We had few issues with users who created their own shortcuts but we worked it out.
I can confirm that so far the only fix I have found is to roll Chrome back to an older version. Since I had a copy of it kicking around, I've rolled back to v65 and have some users testing it at the moment. I think the issue came in at the same time that the Chrome UI changed to the new squarer tabs with curvy corners, instead of the ones with angled corners - version 70 or 71 I think it was. Unfortunately for us, we use Chrome as part of a core business application that is called separately, so passing it parameters at startup is more difficult that just changing a shortcut on the user's desktops.
I've tried installing 32 and 64 bit versions of both consumer Chrome and Enterprise Chrome, latest versions, with no success. So far, the only fix is to roll back the Chrome version - spent hours on it yesterday afternoon and last night. Sounds like I will have to investigate the flags thing further, until and unless Citrix/Google come up with something to sort it.
I've been using Dashboards in 10.7.1 for a couple years with no problem. I generally use Chrome as my browser. I just upgraded to Portal 10.9.1 in a test environment and am setting up a new dashboard. I noticed that my widgets (namely a counter and a serial chart) were not updating after adding new features. Even if I close the browser and re-open.
I was able to have an ESRI tech reproduce it on his side. FYI you'll see slightly different result with map vs feature services. Bug is BUG-000146814. It appears to have started with 10.9.1 and affect any map or feature service with (at least at this point) its data coming from a SQL database. We tested with hosted (in my case Portal but would be teh same for AGOL) and it was not affected. I was able to go a step further outside of dashboard and see stale data at the rest endpoint when querying 1=1. Resolution for me was using a feature service and adding tables via arcade expressions.
There is a bug out there for a issue similar to what you are seeing. I'm experiencing stale data in Chrome, Edge, Firefox for the list and indicator widget. If i use a feature service then just indicator is stale. If you use just map services then the list and indicator are stale. I tried resetting settings in both Edge and Chrome and still see the issue. Bug number is #BUG-000146814. Same kind of deal, upgraded from 10.8.1 to 10.9.1 and now see the issue. I found that if you use feature services and then add them into the dashboard using Arcade with its refresh then the indicator will work.
The problem - Fiddler does not work with chrome. When I open any page on chrome, I get the error "Your connection is not private: Attackers might be trying to steal your information from website (for example, passwords, messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID". FYI, I easily fixed a similar issue with firefox.
Firefox has its own certificate store so I assume you just installed the DO_NOT_TRUST... Fiddler root cert there and everything worked. Pretty much you should do the same with Windows certificate store in order for Chrome to work. So make sure you remove all the fiddler certificates you previously generated and regenerate.
I have tried to download a newer version of chromdriver but it still gives me the same error. I have tried to replace the current chromedriver that's running and the one I downloaded recently but it still gave the same error, so I downloaded the compatible version of chromdriver, and then I used this line of code:
I created an additional passkeys for my Google account to be stored in 1Password. Saving this to 1Password worked, and logging in with this also seemed to work. It's not easy to detect if I used the built in passkeys support or the 1Password passkeys support, but I'm reasonably sure I actually logged in with 1Password's passkey.
Then I went to my Android smartphone and tried logging in to the Microsoft account in chrome - anything except push notification and password isn't offered, so I assume passkeys is only supported for the desktop currently.
Then I went to a Windows 11 desktop (it's a vm, accessed it with rdp, so without Windows Hello!) where I never used passkeys before. I tried logging in to the Microsoft account with Chrome. Lo and behold, it pulled the cloud-synced passkey from 1Password! This worked!
Then I tried to login to my Google account on that machine. This wasn't successful. Google asked for my password and didn't offer any other option except sending the usual push notification to the smartphone.
After I successfully logged in with that, Google offered activating passkeys. I started the workflow, however it wanted to create a new Passkey and the 1Password browser plugin offered saving this to 1Password. Since I already had a passkey for this account in 1Password, I stopped and didn't save another one - I guess it's supposed to have only 1 passkey for the same service in 1Password (in this case: my Google account).
So this was half successful: unable to pull an existing passkeys from 1Password for use with Google, but successful in recognizing the passkeys generating and storing workflow. Might have to do with the rdp connection and missing Windows Hello. Unfortunately, I don't currently have a second physical desktop machine to test a cloud-synced passkey on a local machine without rdp.
1Password saves a passkey when I set one up in the Google account, but if I log out and try to log back in with a passkey, Google only offers me the opportunity to log in with my Android phone's auto-generated passkey, and not with the 1Password-saved passkey. If I pick "use another device", Windows Hello! prompts me to insert a physical security key (which I don't have) instead of using my actual Hello! authentication method.
I tried the same with a Google account. I am currently testing with one instance of Google Chrome on a Mac, on an Incognito session. I successfully added a Passkey and have been able to use it to log in again after logging out.
I've tested with Google and Home Depot, by the way. In all cases, 1Password shows a little passkey icon for the account but the web site is going through its normal login process. Then once I'm logged in, it sometimes asks me if I want to create a passkey. But it doesn't see the one I already have.
I also couldn't get Chrome to give me the option to log in with a Passkey if I hadn't created the passkey in that particular instance of Chrome. The fix I found (through another post here) is to copy/paste "chrome://flags/#enable-debug-for-secure-payment-confirmation" into the address bar of Chrome, and then disable the feature that comes up.
I want Chrome to open all .html files. It is currently set as my default browser, however html files open in IE9. When I go to Control Panel\Programs\Default Programs\Set Associations I see that .html and .htm files are associated with IE. When I choose to change the default program it I'm presented with a list of programs but Chrome is not one of them. I browse to, and then select the Chrome.exe (C:\Users\Matt\AppData\Local\Google\Chrome\Application\chrome.exe) but it goes right back to IE. This is the first time I've seen anything like this. I'm running Windows 7 64 bit. I never had this problem on Windows 7 32 bit.
EDIT: It's not that things are reverting back to IE after associating them with Chrome. When I browse to Chrome in the file association window, and select it, it doesn't seem to take. It doesn't show Chrome in the list of programs despite pointing to the Chrome.exe location. I really think this has something to do with the fact that it doesn't install into the Program File Directory.
On iOS, I have Safari, Chrome (for Facebook only, again, little risk of data collusion between FB and Google) and Opera. I never use Google services on Mobile other than through IMAP or CalDAV. And of course I use a gauntlet of content blockers with Safari.
I get your point but still tend to side with the noob counterargument. Anything I want to keep seriously private will have no place on a computer with any kind of web connection. For the rest I acknowledge that privacy is just an illusion.
google like any corporation is headless, drivin only by profit margins, its a simple formula and clearly a asymmetric tradein there favor, if the risk is loosing a few million users now to gain every future users browsing data than that is a favorable trade. and of course sync is still opt in, sync data is the main service they offer you as trade for your valuable browsing data so if they can collect your valuble data without having to provide a expensive service that makes the trade even more asymmetric in there favore and that in the end is why i and many others dumped chrome, the only way google will ever care is if enough fuss is raised to hurt there reputation or bottom doller otherwise we are a calculated loss and most of the privacy concerned users didnt share data anways and earned less revenue. (sadly posted from f droid firefox )
dafc88bca6