Is there a way that we can determine if the Google Chrome extension got added through profile sync.
I need the my extension to be functional only the first device it was added not on other devices where it got added through profile/auto sync option.
Is there a way that it can be determined?
Related
I'm using a Chrome Extension, which I like a lot, but it shows notifications, which I find distracting. I want to disable those notifications. I'm using Linux Mint, and the notifications are shown in the panel (at the bottom of the screen).
I've checked chrome.management API, but haven't found anything related to disabling notifications. Also googling didn't provide any results.
The only way I can think of is installing the same
extension via Developer mode, creating a system script that would be watching the original Chrome Extension folder for changes, and on every change, copy the content to the Developer Mode folder (modified), modify it after each update to remove the notifications permission, and then reload the Developer Mode extension inside Chrome via a shortcut, for example.
I'm wondering if there is any simpler way to accomplish this.
I have an unlisted extension published through the Chrome web store which is already being used. I have a new version which I would like to release just to testers initially, before a full roll out to everyone. Can this be done?
The same thing has been asked here but it was almost 9 years ago, and the answers disagree on whether it's possible or not:
How to publish new version of Chrome Extension only to testers
The short answer is "No, it can't be done for a published extension".
According to Chrome Web Store visibility descriptions, you must unpublish an extension before it can be published to trusted testers. Users who already have it installed will get updated to the new version.
In your case, you have to create a new extension with the new code, and a different name like "MyApp Beta" and publish it privately to the list of trusted testers.
Maybe you already know this, but you can install a chrome extension manually.
Go to chrome://extensions/ and check the box for Developer mode in the top right.
Click "Load unpacked exention"
Select the folder where your unzipped extension resides in.
So, you can send a zip/rar to your testers, let them follow the procedure and test the extension. Might be that you have to give it another name so as to not conflict with your earlier eversion, or you could ask your testers to delete the existing extension to avoid conflicts.
Well, the simplest way is to pack a .crx file of the tester-only extension then link to it via some cloud-hosting service like Google Drive. There is no way to do this through the Web Store. You could release a different extension as a beta channel though.
Not strictly related to publishing a full extension, but ... you could use feature toggling to control the visibility of new functionality? So wrap the new functionality in toggle checks and only turn the feature on based on some criteria you can decide in a custom roll-out strategy. See enter link description here for an open-source implementation of a feature toggle control system.
If you have a developer account and want to publish it on the chrome web store privately to just testers this is what you have to do:
Go to the Pricing and Distribution page of the extension during the publishing process
Click "Private"
Go to your developer account settings, and in the "Management" section, you can add trusted tester accounts.
You can change the status to public whenever your extension is ready.
Background
I've been using the crx-hotreload package to auto-reload my chrome extensions during development because it's annoying to have to click the refresh button on the Extensions page every time you make a change; however, this package doesn't work with MV3 because it uses the chrome.runtime.getPackageDirectoryEntry method, which seems to have been removed from chrome.runtime in MV3. I can't find documentation to confirm that it was removed, but it's not there when I try to use it.
Questions
Does anyone know how to get access to all the files in the extension directory in Chrome Extension Manifest Version 3?
Or generally, is there a better way that I can hot-reload my chrome extensions during development that would work for MV3?
This is one of many things based on DOM capabilities of background pages that are removed from ManifestV3 because service workers don't have DOM. For example, getPackageDirectoryEntry is using the old nonstandard FileSystem API in its returned value.
As to why, apparently the switch to service workers simplifies the internal source code in Chromium, even if it doesn't provide any real improvements for extension authors or users.
At this point all you can do is present a convincing use case and ask Chromium developers via https://crbug.com to implement an alternative API.
I'm diving into the world of Chrome Extension development, primarily because there is a very small feature that is missing in Chrome that I miss dearly. The context-menu option to "Set as background/wallpaper" like that found in Firefox. Sounds trivial, but it's convenient.
I have most of the "basic" stuff worked out with the manifest file, am able to install it, even managed to get it to show up as a context menu item.
The problem obviously is that I am wanting to mess with a user's OS-level settings which is extremely difficult because of security issues (fully understand this).
I found an extension that allowed this in older versions of Chrome, and it looked like the developer used some type of .dll and C++ to accomplish this.
I'm not really sure how to make this work.
Since that Chrome doesn't allow these kind of manipulations (such as your PC's settings), you will need to create a native application that will run beside your extension. When the user chooses the image from your extension and selects "use as wallpaper", you will use the native messaging API to send a message to your desktop application, that will set the wallpaper (and do whatever else you can't do within a chrome extension) for you.
You can use the chrome.wallpaper app api to set the wallpaper after using the messaging api to send the image from your extension.
Is there an API for a Chrome extension to launch and control new Chrome windows under different user profiles?
My understanding is that while an extension may be run under multiple user profiles simultaneously, these instances are isolated; they cannot communicate directly and an extension in one profile cannot access the windows/tabs/processes/etc of another profile. Is this the case?
It seems like the best way to launch and control Chrome windows under multiple profiles is to use an approach based on the Remote Debugger API such as the ChromeDriver project.
For context, I'm interested in writing a tool to manage and launch predefined "bundles" of multiple Chrome windows, each with different URLs and screen positions, and each under a different profiles. The attached screenshot shows an example desired state: three browsers, each in a separate profile, each at a different URL, with different devtools states, organized in a specific screen layout. It is conceptually similar to tmuxinator.
If I wanted to provide a Chrome-based UI for designing and managing these presaved layouts, it seems that I would need to provide a native shim that invokes new Chromes via chromedriver, and communicate with them via native messaging. Is there a more direct API that I am missing?
It seems that the proposed Profile Extension API would do exactly what I'm interested in, but I don't see any discussion on the apps-dev#chromium.org list.
If chrome allowed this it would be a huge security hole.
Chrome extensions are installed per user account so they shouldnt be able to see anything from other accounts.