Packaging Chrome extension with a sidebar - google-chrome

I'm trying to create an install package of my extension. It uses chrome.experimental.sidebar API. When I create the package and install it, everything works just after teh install. When I restart Chrome I cannot open the sidebar - it doesn't show. The onclick method works - I've added an alert to show at the end of it.
I turned on using experimental API in chrome://flags. When I use the extension installed in a folder everything works great.
Am I doing something wrong or does Chrome disallow using expermiental API from packages?

Can you include the manifest file that you're using? Chrome has a known bug where an empty manifest value (e.g. "sidebar" : {}) will not be preserved across restarts. Adding a dummy value inside the sidebar dictionary should prevent this.

Related

Chrome's map to file system resource not working after update

I can add a folder to the workspace (which doesn't seem to do anything, as far as I can tell), but the "map to file system resource" option seems to have been removed, and I can no longer live-edit css files.
Is this a bug, or has the process for mapping css files been changed?
This talk (https://developers.google.com/web/updates/2017/10/devtools-release-notes) says that the new version uses "magic" to map remote files to local ones, but I can't seem to get it to work at all.
For reference, I'm trying to map a reddit css file to one on my own computer. It worked fine on a previous version of Chrome (basically I add the folder, and map the css file inside it, which has been renamed to have the same name as the remote one) but not on the new one (Chrome 63)
I've just fiddled around with a problem, where only some files got mapped to my local workspace.
Turned out that Google Chrome also checks and compares the last modified date of your files.
If the file on the server has a more recent date than your local copy, this file won't be mapped.
I deleted the Bootstrap file on the server side and uploaded my local copy, which has an older last modified date. Google Chrome instantly mapped the file to my local workspace.
Out of curiosity I ran touch bootstrap.min.js on my server to set the last modified date to today. This broke my file mapping again.
Chrome removed manually mapping to filesystem resources because of the new Workspaces 2.0 (See: https://developers.google.com/web/updates/2017/10/devtools-release-notes).
You should be able to drag and drop your folder into the sources tab and it'll link the files automagically.
However automatic mapping doesn't work in many situations and there is a Chrome bug to re-add manual mapping
I had the same problem so I downgraded to Chrome 62 (preferences, history, extensions and so on are preserved).
Download Chrome 62 from
https://www.slimjet.com/chrome/google-chrome-old-version.php .
On OS X trash /Applications/Google Chrome.
Switch off auto-update by setting "defaults write com.google.Keystone.Agent alwaysPromptForUpdates 1". Default is 0.
May be you have to set "defaults write com.google.Keystone.Agent checkInterval 0" too. Default is 18000.
Install Chrome 62 as usual.
After starting Chrome 62 open "About Google Chrome". Chrome is checking for updates, but will prompt you to confirm.
The "Map to File System Resource..." menu item is missing. There appears to be no way to map files. It is completely broken as far as I can tell.
For me, the problem turned out to be the presence of the copyright symbol © in the file headers (which affected just about every file). With this character in the files, devtool refused to map the files but with it removed, the files map fine.
I'm also using Chrome 63.0.3239.132 (Official Build) (64-bit) and as I wanted to use the DevTools Live-edit to edit some js files I saw that the option "Map to file system resource" is missing.
After some research I have found out that the Live-edit is perfectly working in Version 63, you just have to:
go to Sources and then FileSystem
add the folder with your code to the workspace
After that, a small little green point will be displayed near your files (it means the synchronization is ready) and the changes via DevTools can be persisted locally:
Thanks to others in this thread saying chrome is checking the modified date.
Adding this to .htaccess solved it for me
IndexOptions SuppressLastModified
Of course you would not want this to get into your production code as it could stop browser caching working.
I cleared the cache and it works now.
Previously, I opened my CSS file from my FTP client, then I dragged the containing folder into the Sources tab > Filesystem tab (without caring about any folder names nor structure, I just dragged the FTP clients containing folder into it).
The persistent mapping worked straight away, edits from the Chrome Dev Tools were saving on the server. After 30 minutes of fiddling and playing around, it just stopped working and the CSS resource got greyed out. The file icon with the green dot was not appearing anymore.
It didn't matter what I'd do, it would not work, but when I cleared my cache, it started to work again.
File mapping started working reliably for me once I turned on a devtools setting -- click the upper-right gear icon and check Preferences > Network > "Disable cache (while DevTools is open)"
As of today, with Chrome Version 63.0.3239.108 (Official Build) (64-bit):
The feature appears to be still broken, not working 'automagically' nor consistently with the previous behavior.
However, adding a folder that reflects the resource's URL as seen in the Network tab, make it work again. So if for instance, in the Network Navigator tab you have:
http://mylocal.site/wp-content/themes/mytheme/assets/sass/partials/_header.scss
You will just need to add the whole wp-content/ folder to the Filesystem tab to get the feature work again as expected.
Had the same problem, but when my source maps included sourcesContent, the file mappings were automatically made and I could live edit my scss. Apparently chrome uses the content to find the right file.
node-sass --source-map-contents

"unsafely-treat-insecure-origin-as-secure" flag is not working on Chrome

I am using geo-location for a site running locally on my machine using HTTP on Chrome. However this does not work as I am running on HTTP as opposed to HTTPS.
On the console it says:
getCurrentPosition() and watchPosition() no longer work on insecure origins.
To use this feature, you should consider switching your application to a
secure origin, such as HTTPS. See https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-powerful-features-on-insecure-origins
for more details.
Accoriding to Deprecating Powerful Features on Insecure Origins its says to start chrome using --unsafely-treat-insecure-origin-as-secure="http://example.com" flag. The command I ran was similar to:
chrome.exe --unsafely-treat-insecure-origin-as-secure="http://hello.app"
However, the same error message still appears.
How can I fix this issue.
None of the solutions worked for me.
I achieved this by following steps.
Type chrome://flags/#unsafely-treat-insecure-origin-as-secure in the address bar.
Add the origin which you need to treat as secure as shown in the below image.
Relaunch chrome.
You must have missed some steps. Try to follow this
Go to File Explorer then paste this to address bar >> C:\Program Files (x86)\Google\Chrome\Application (or just go to where you can find your chrome.exe)
Right click chrome.exe > send to > Desktop (Create Shortcut)
Go to your desktop then find the chrome shortcut you've created.
Rename it to ChromeForTesting (this step is optional)
Right click the shortcut, then Click Properties
At the "Target", paste the following at the end of the link
--user-data-dir=/tmp/foo --unsafely-treat-insecure-origin-as-secure=http://example.com
so Target should look somewhat similar to this
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --user-data-dir=/tmp/foo --unsafely-treat-insecure-origin-as-secure=http://example.com
Click Ok..
During testing close all of your opened google chrome browser.
Then double click ChromeForTesting shortcut (the one you've created), when a prompt appears, just click ok..
EDIT: If the steps above does not work for you, you might be using Chrome V63, update it to V64 above cause this flag is messed up in V63.
P.S. If it's still not working follow these extra steps
At your drive C, create a folder and name it "ChromeTempFiles".
Then in your --user-data-dir= you change the value into "C:\ChromeTempFiles"
Add these to your target as well
--allow-running-insecure-content --reduce-security-for-testing
so your target should look like this now
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --user-data-dir=C:\ChromeTempFiles --unsafely-treat-insecure-origin-as-secure=http://example.com --allow-running-insecure-content --reduce-security-for-testing
You should also use a temproary fresh profile for that session. something like this:
chrome.exe --user-data-dir=/test/only/profile/dir --unsafely-treat-insecure-origin-as-secure="http://example.com"
Just an update to this for Chrome 70. This works perfectly
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --user-data-dir=C:\ChromeTempFiles --allow-running-insecure-content
Now does anybody know if there is an equivalent for firefox?
For Chromium 44 use
--unsafety-treat-insecure-origin-as-secure=http://192.168.0.101:3000
instead
--unsafely-treat-insecure-origin-as-secure=http://192.168.0.101:3000
See that bug
In Google Chrome, you simply type into the address bar, "chrome://flags", and search for, "--unsafely-treat-insecure-origin-as-secure", enable that flag, and enter into the field below (multiples may be entered separated by a comma) the domain you wish to treat as secure. This may or may not compromise your security, but I would assume not as getCurrentPosition() and watchPosition() are somewhat recently deprecated features. this works for publicly served domains, as well.
With Chrome 79 this setting doesn't work no matter what.
What I ended up doing was to configure the domain on a VPS to show some test webpage and then generate a valid certificate for it using Let's Encrypt's certbot.
Then I copied that certificate to my machine and it's now valid.

Chrome --load-extension doesn't work on some machines

I'm trying to load unpack extension using command line flag --load-extension.
I'm using one chrome profile. The syntax for query is following:
chrome --load-extension="C:\Users\someUser\Desktop\unpackExtensionFolder"
Inside unpackExtensionFolder there is manifest.JSON and all sources.
This command doesn't work on few PCs in office, but it works on the rest of them, and successfully loads the extension (Chrome version is the same on all machines - 31, extension that we are trying to load is the same).
Discovered:
Doesn't depend on chrome profiles amount
Doesn't depend on developer mode on/off
The question is why? And what could have influence on this?
The reason for this was plugin inside manifest file, seems that chrome was not able to load extension with plugin declarated in it. Works fine after removing plugin section.

Change to this file were not saved to file system error in google chrome version 30.0.1599.101 m

In the google chrome version 30.0.1599.101 m I am not able to save the changed js file.
On saving the js file I got yellow triangle symbol with "change to this file were not saved to file system" message.
I know this used to work in older version
I am using windows-7 64 bit
Click on the cog in the developer tools window (lower right corner)
Go to workspace and add the directory which you would be working on.
This is to accidentally prevent you from modifying files that you did not intend on changing.
Happened to me too. After picking the workspace directory, I also mapped the file from the "Source" panel of Devtools to its filesystem equivalent (using right-click on the file, from the file tree). It solved my problem.
In chrome > 63, accepted answer option is disabled.
In later should be done through workspaces.
Tonight, I accidentally managed to fix this problem, just open the file on the disk and save it with a simple change even with a space.
Refresh the page in Chrome, Chrome will link it(The file) to the disk.
Using Ctrl + F5 to clear the browser cache worked for me.
I found nothing in "workspace" that seemed relevant, and other things people listed didn't help either. What helped was to go in dev tools, where it says Pages, Sources etc., there is also Overrides (duh :)), I chose it, it said "Select folder for overrides", I did, and then also clicked "Allow" on Chrome asking for confirmation. That's it, after that I was able to save the files, the overrides worked.
Ok, my case might be a bit different but I will share my experience on what I was facing that caused to this warning and how I solved it.
I was trying to check a certain strange behavior on a React app for video streaming, so I opened up Developer console, enabled local overrides and tried editing the js file, immediately upon saving I got the warning “Changes to this file were not saved to file system”.
Note the message at bottom right “Source mapped from app.bundle.min.js”, this indicated that this is not an actual file but a mapping from the app.bundle.js (Webpack bundle)
So I moved to editing the app.bundle.min.js, I searched the appropriate string I was interested in from the mapped file (react-dom.production.min.js) and searched it in app.bundle.min.js
Again I got the same warning but I noticed the “app.bundle.min.js” file was fetched using a url parameter ?v=4900, I decided to remove it to check if that was the culprit causing the issue, to achieve that I modified the index.html file and edited the script tag that was fetching the js file from
<script src="libs/app.bundle.min.js?v=4900"></script> to <script src="libs/app.bundle.min.js"></script>
After that I forced refresh the page (Shift+F5, normal refresh didn’t work), tried modifying and saving and Jackpooot!! (Take away: You can’t override files fetched with a url parameter). I then was able to beautify, modify and override the app.bundle.min.js implementation and achieved what I wanted.
On Chrome Version 109~ :
Go to F12 > Sources Tab > Overrides (You may need to click the chevron next to Page)
Select/Create a folder to contain Overrides
You can now right-click a file or editor window & save it for Overrides
Image of sources tab where Overrides is located
Something to note: if you are making dynamically loaded JS available in devtools via the helpful: //# sourceURL=Example.js comment, this network to local mapping will not work.
Note: Notice the "//# sourceURL=dynamicScript.js" line at the end of dynamicScript.js file. This technique gives a name to a script created with eval, and will be discussed in more detail in the Source Maps section. Breakpoints can be set in dynamic JavaScript only if it has a user supplied name.
https://developer.chrome.com/devtools/docs/javascript-debugging
When you're using sourceURL, you can't actually find the respective JS file in the Sources tree where you might expect it to exist. It is available to open via the "no-domain" tree, however (or quick open with CTRL/CMD+P).
I'm still looking for a solution.
The easiest solution I found to this problem:
(keep in mind, I was manipulating an html page that lives on my machine)
open the associated html page from the command line so the page displays
for mac, that's simply $ open <name>.html
open Dev Tools
open Sources tab
in Page, open a new .js file there with whatever name you need
write in some text and save
This worked for me. Yes, I had to create a new .js file, but my directory locally recognized it was there when I pulled it, and my editor was updating in real time with the dev tools each time I saved either. At that point, my editor and the dev tools source tab had become one thing.
Currently on Chrome 100.0.4896.60 (Official Build) (x86_64).
I've got a js file with source maps; the override has always been spotted.
I'm able to override the map file (which won't work though for the debugging purpose) and the index.html file.
Apparently my issue is related to minified js with source maps.
Seem to work in relation to the chrome version installed.
I tried the following attempts but didn't work:
remove cache
disable / enable override
add the dir to the workspace
install chrome canary
To debug then I've tried:
build my file.min.js to test. In my case was production/file.min.js
start a npx http-server in production (cd production && npx http-server) which open to http://127.0.0.1
override index.html to consume http://127.0.0.1/file.min.js
Interesting considerations:
When i was doing basic overriding i had to replace the file manually all the times.
Now, I've got a watch task going on and i can basically refresh the page.
I can see as well the source map update.
It's simple! Right click on your page, Go to Inspect, go to the Network tab and tick the check box 'Disable cache'. Reload the page and you will see the effect.

Chrome Inline Install for extension not working

I'm trying to use the new chrome inline install feature for extensions (see here: http://code.google.com/chrome/webstore/docs/inline_installation.html).
I can't get it to work unfortunately, and have very little clues to go by. I've added the link element to the head element
<link rel="chrome-webstore-item" href="https://chrome.google.com/webstore/detail/pnnfemgpilpdaojpnkjdgfgbnnjojfik">
and I call
chrome.webstore.install();
in a jquery event handler. I've also verified my domain, however, I'm testing this on a local machine but have a subdomain pointed to my localhost (i.e. testing on dev.getbentobox.com which is mapped to localhost in my hosts file if that makes a difference).
When stepping through my js using the chrome debugger, chrome.webstore.install() is getting called and the function is defined. However, nothing happens - no install, no javascript exception, no console printing, nothing.
any ideas?
Your Chrome Web Store item doesn't show the verified site. If you compare it to the "We Heart It" extension, which can be inline installed from http://weheartit.com/heart-button, it has a green check saying "from weheartit.com". You'll need to edit your Web Store item, and associate your verified site with the item.
As of December 2018 (Chrome version 71), Google has disabled this feature. The workaround is to send the user to your extension in the Chrome Web Store.
Source: https://developer.chrome.com/extensions/inline_faq#change_dec18
What will change in M71 (Dec 2018)?
Beginning in M71, Chrome will no longer support the chrome.webstore.install() method and calling it will fail, resulting in a broken installation flow on your site. At this point calls to the API will throw a JavaScript TypeError. You should remove any calls to the API method before this date.