I have a problem with my Chrome Extension that that depends on the
chrome.tabs API.
My extension is mostly running normally. Sometimes I do a
chrome.runtime.reload() and that works mostly without problems, but
now and then (I have neither been able to predict when or reliably
replicate it) when the background script comes back after the restart
the chrome.tabs reference is undefined. Since I depend on that API
the extension can't start. That scenario can be detected, but when I
try to do a chrome.runtime.reload(), chrome.runtime.reload is also
undefined. So then I don't have a method to restart again.
I realise that I probably ought to develop soft restart capabilities
for my extension to return to a blank state, but that's very work
intensive, so I wanted to ask the community if anyone else have any
experience with this problem, and in that case, how have you solved
it?
Here is my permissions from the manifest.json file:
"permissions": [
"tabs",
"contextMenus",
"webNavigation",
"webRequest",
"webRequestBlocking",
/* some whitelisted web URLs... */
Thanks a lot #Xan for
pointing me towards this
other
question that seems to cover the exact same phenomenon.
I have decided that enough indications point towards this being a bug
in chrome's handling of background pages.
I also have some additional observations:
The question pointed to by #Xan have references to a likely bug in
Chrome's background pages.
When I replicated the bug by calling chrome.runtime.reload() in my
background page's developer tools console I found that
chrome.runtime.reload() was available as usual to my extension's
popup UI.
Background pages are not (yet) deprecated, but the first line in the
documentation
recommends migrating to event pages instead, they can't possibly be
high on the Chromium team's priority list. In other words, I consider
the risk of this bug - if it is one - to have a high risk of being
categorized a 'wontfix', therefore, it looks unproductive to try
to wait out a fix.
Therefore, I have devised a workaround that I think will be
satisfactory until I have the resources to either develop
soft-restart capabilities in my extension OR migrate to event pages:
Given that:
Most of my extensions functionality is triggered via a Chrome
browserAction. Before the browser action starts to render, I can
post a message to the background page that I know will call back
immediately.
When the extension have started normally, the fix will simply be a
no-op invisible to the end-user.
Since the fix normal operation is a no-op the fix won't hurt the
extension should the Chromium team fix the bug in a future release.
"Dead" background pages will have failed to register any message
listener. If the background page doesn't respond to the safety check
message, the popup can fix the broken state by restarting the
extension.
This comes at a cost: if the popup times out waiting for the 'safety
net' message and restarts, the popup UI will be brutally closed
without warning from under the end user's feet. Not nice - but after
some consideration I have decided that I think that behaviour is far
preferable to the extension just silently stopping working like it
can do now.
Comment if you have further ideas!
Related
I'm working on Chrome extension which needs to perform an action just before Chrome closes. Is there any method like chrome.window.onClose.addListener(...), or chrome.runtime.onClose.addListener(...) to ensure that something will be done and then chrome will close itself?
I've been struggling with this problem for two weeks. Here are the options for potential solutions that I've found, but they didn't work.
My investigation results:
Using function: chrome.runtime.onSuspend.addListener(...) - I don't know why, but it doesn't work at all for me. For example, I've tried to write a callback for this event, which tries to add hardcoded data to the indexed DB, but it doesn't add it. Description of this method even says that the callback is not guaranteed to be completed. OnSuspend documentation
Sent to the event page just before it is unloaded. This gives the extension opportunity to do some cleanup. Note that since the page is unloading, any asynchronous operations started while handling this event are not guaranteed to complete.
Chrome working in a background - with this option my extensions seems to work, but... only on Windows older than Windows 10. I've checked few options and on my other computer, which has Windows 7 installed, processes connected to Chrome are closing more slowly, which gives time for my extension to perform necessary tasks. Unfortunately, Windows 10 kills all the processes much faster. I've check option "continue running background apps when google chrome is closed", but it doesn't change anything. I've also enabled flag "#enable-push-api-background-mode", it hasn't helped either.
Keep Chrome running in the background on Win10, Enable flag to keep Chrome processes running
chrome.app.window.current().onClosed - I've found a similar question on Stack Overflow, and one of the answers was the code mentioned above. The problem is when I try to type chrome.app.win... inside console, it doesn't show any suggestions both in background script and content script. Google's documentation doesn't mention any permission that I've to add inside my manifest.json to get access to this functionality.Stack Overflow similar question, Google's documentation about chrome.app
Methods build in web browser - I've thought that method window.onclose might be useful in my case. I've performed the same test as for chrome.runtime.onSuspend, but the result was exactly the same. Documentation
I've stuck and haven't got any idea how to solve my problem. Maybe I missed something important? Hope you will help me.
First some backstory:
We have a website that includes a Google Map in the usual way:
<script src="https://maps.googleapis.com/maps/api/js?v=....></script>
Then there is some of our javascript code that initializes the map. Now suddenly yesterday pages started to load but then freezed up entirely. In Chrome this resulted in having to force quit and restart. Firefox was smarter and allowed the user to stop script execution.
Now after some debugging, I found out that a previous developer had included the experimental version of the Google Maps API:
https://maps.googleapis.com/maps/api/js?v=3.exp
So it's likely that something has changed on Google's servers (which is completely understandable). This has uncovered a bug on our end, and both in combination caused the script to hang and freeze up the website and the browser.
Now ok, bug is found and fixed, no big harm done.
And now the actual question:
Is it possible to somehow sandbox these external script references so that they cannot crash my main site. I am loading a decent amount of external javascript files (tracking, analytics, maps, social) from their own servers.
However such code could change at all times and could have bugs that freeze my site. How can I protect my site? Is there a way to maybe define maximum allowable execution time?
I'm open to all kinds of suggestions.
It actually doesn't matter where the scripts are coming from - whether an external source or your own server. Either way they are run in the clients browser. And that makes it quite difficult to achieve your desired sandbox behavior.
You can get a sandbox inside your DOM with the usage of iframes and the keyword "sandbox". This way the content of this iframe is independent from the DOM of your actual website and you can include scripts independent as well. But this is beneficial mainly for security. I am not sure how it would result regarding the overall stability when one script has a bug like an endless loop or similar. But imho this is worth a try.
For further explanation see: https://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/
Recently, we found that Firefox had made a change towards plugins, such that the user will be temporarily blocked from running them if they are not using the latest version. Our site requires Flash to play sound and interact with the user's webcam/microphone, so we need to do whatever we can to ensure they're not getting these warnings.
One way suggested to me is to create a small Flash control, and wait for it to tell Javascript that it's been initialized. If not (and the user is using Firefox) then they are taken to a page prompting them to update. This may work, but I worry about its reliability, and about running it on every page in our site.
Alternatively, I've been researching a way to use Javascript to detect versions, without making a Flash control. I not only need the user's current version of Flash, but also the version Firefox will expect - and I haven't found an autonomous way of doing so. I don't want an admin to have to change a small value each time Adobe releases a new version. Does anyone have any advice how I could find Flash's latest available version, or an alternate way to solve my problem?
I recommend you have a look at SWFOject and the Express Install option which should ease upgrading considerably.
I just noticed someone upvoting this question, so I thought that I would provide my eventual solution, which I think reduced the impact of a recent issue where Firefox blocked the most recent edition of Flash, pending Adobe's fix.
Basically, I went with a variation on the second paragraph in my question. It does not direct the user to a new page; instead, it opens a dialog over the current page that explains it's having issues communicating with Flash. (It does not specifically say "Your Flash is out of date" because this can also happen if the browser is hiding flash under a Yes/No user dialog). It also contains a small fake flash object, with the idea being that if the browser wants to display a security warning, accept prompt, etc., it can do it inside that space.
The dialog goes away on its own if said Flash control ends up making its callback to JavaScript. It also installs a variable under sessionStorage so we don't bother checking for it again (Flash takes enough time on some computers that you might see the dialog for a split second).
I manage an e-commerce site running under SSL.
The problem is happening on the final page of my site's shopping cart that loads under SSL. The problem is that Internet Explorer 8.0 (including version 8.0.6001.18702 and other versions of IE8, but reportedly not all versions of IE8) complain about at least one non-secure element loading, which is scaring away some of my prospective customers. IE8 displays a dialogue box after the page has apparently fully loaded (with seemingly no missing images) that says:
"Security Warning: Do you want to view only the web page content that was
delivered securely? This webpage contains content that will not be delivered
using a secure HTTPS connection, which could compromise the security of the
entire web page. (YES/NO)"
I tried to track down all invalid images and links that may be loading via HTTP, but no to avail. Firebug Lite shows nothing non-secure. I'm starting to think this may be a bug within IE8 that was corrected in IE9, which does not complain.
TO REPRODUCE THIS ERROR: Click here using IE8 (or Chrome) to add an item to your shopping cart. On the resulting page, click on the GREEN button on the right that says, "Proceed to Secure Checkout." You will notice that you see the above "Security Warning" from IE8.
QUESTION: How can I determine what the browser is attempting to load non-securely, or how can I suppress the "Warning" message?
UPDATE: It seems the "Security Warning" is due to the suspended JavaScript execution on this page. But the same question still remains. How can the "Security Warning" message be suppressed or "debugged"?
Wireshark is usually pure overkill if its used to debug standard web browser based applications because it provides way to many information which are usually not required to exactly pinpoint the problem. A much better solution in this case would be to use Fiddler which is a simple yet a very powerful debugging proxy which is, aside from its many useful functionalities, also able to clearly distinguish between SSL and non-SSL traffic.
Its also able to simulate a "man in the middle" testing environment which effectively allows it to decipher SSL traffic. Of course the generated "on the fly" certificate is clearly marked as untrusted in all browsers to prevent misusing it.
EDIT: I followed the given instructions in order to provoke the problem yet I had no problems with any kind of security warnings in IE8. Also Fiddler is showing that all the resources are loaded through SSL.
I know this is an old post, but since there wasn't an answer posted that fixed my similar situation, I thought I'd shared what I found in case anyone else stumbles onto this page. If you use removeChild() to remove an HTML element that contains an inline style setting a background image, the warning occurs in older versions of IE8. You can get rid of the warning by moving the inline style setting the background image into a style class set in the HTML head or external style sheet.
See this Microsoft KB Page, which says the glitch only occurs in IE6 and IE7, but it happened to me on IE8 on XP, too, and the same fix worked.
I ran into a similar problem in the past with IE8, and what it appeared to be was an issue with cached items. I wasn't able to completely pin it down because, like you, I checked every asset and found nothing that was not loading via SSL. However, I noticed that if I prevented all caching and forced IE to load all assets from the server, the warning disappeared.
I don't know if there's a bug where certain items pulled from cache don't get recognized as secure, but it seemed to have something to do with it.
Disabling caching is obviously a bad way to solve a problem that only impacts a subset of browsers, but it might be a tip that could lead you in the right direction.
Click checkout at the top of the page?
Not in https anymore is it?
If you have SSL-backed pages, then every assets (js, css, images) should be served by HTTPS protocol too. It's the same behaviour for 90% browsers
As Jon stated:
If you use removeChild() to remove an HTML element that contains an inline style setting a background image, the warning occurs in older versions of IE8. You can get rid of the warning by moving the inline style setting the background image into a style class set in the HTML head or external style sheet.
While the Microsoft KB Page does provide the fix, the best solution is to implement it as follows (place in a script at the bottom of your page):
Ext.removeNode = Ext.isIE ? function(){
return function(n){
if(n && n.tagName != 'BODY'){
n.outerHTML = "";
}
}
}() : function(n){
if(n && n.parentNode && n.tagName != 'BODY'){
n.parentNode.removeChild(n);
}
}
Recently I have been having issues with Firefox 3 on Ubuntu Hardy Heron.
I will click on a link and it will hang for a while. I don't know if its a bug in Firefox 3 or a page running too much client side JavaScript, but I would like to try and debug it a bit.
So, my question is "is there a way to have some kind of process explorer, or task manager sort of thing for Firefox 3?"
I would like to be able to see what tabs are using what percent of my processor via the JavaScript on that page (or anything in the page that is causing CPU/memory usage).
Does anybody know of a plugin that does this, or something similar? Has anyone else done this kind of inspection another way?
I know about FireBug, but I can't imagine how I would use it to finger which tab is using a lot of resources.
Any suggestions or insights?
It's probably the awesome firefox3 fsync "bug", which is a giant pile of fail.
In summary
Firefox3 saves its bookmarks and history in an SQLite database
Every time you load a page it writes to this database several times
SQLite cares deeply that you don't lose your bookmarks, so each time it writes, instructs the kernel to flush it's database file to disk and ensure that it's fully written
Many variants of linux, when told to flush like that, flush EVERY FILE. This may take up to a minute or more if you have background tasks doing any kind of disk intensive stuff.
The kernel makes firefox wait while this flush happens, which locks up the UI.
So, my question is, is there a way to have some kind of process explorer, or task manager sort of thing for Firefox 3?
Because of the way Firefox is built this is not possible at the moment. But the new Internet Explorer 8 Beta 2 and the just announced Google Chrome browser are heading in that direction, so I suppose Firefox will be heading there too.
Here is a post ( Google Chrome Process Manager ),by John Resig from Mozilla and jQuery fame on the subject.
There's a thorough discussion of this that explains all of the fsync related problems that affected pre-3.0 versions of FF. In general, I have not seen the behaviour since then either, and really it shouldn't be a problem at all if your system isn't also doing IO intensive tasks. Firebug/Venkman make for nice debuggers, but they would be painful for figuring out these kinds of problems for someone else's code, IMO.
I also wish that there was an easy way to look at CPU utilization in Firefox by tab, though, as I often find myself with FF eating 100% CPU, but no clue which part is causing the problem.
XUL Profiler is an awesome extension that can point out extensions and client side JS gone bananas CPU-wise. It does not work on a per-tab basis, but per-script (or so). You can normally relate those .js scripts to your tabs or extensions by hand.
It is also worth mentioning that Google Chrome has built-in a really good task manager that gives memory and CPU usage per tab, extension and plugin.
[XUL Profiler] is a Javascript profiler. It
shows elapsed time in each method as a
graph, as well as browser canvas zones
redraws to help track down consuming
CPU chunks of code.
Traces all JS calls and paint events
in XUL and pages context. Builds an
animation showing dynamically the
canvas zones being redrawn.
As of FF 3.6.10 it is not up to date in that it is not marked as compatible anymore. But it still works and you can override the incompatibility with the equally awesome MR Tech Toolkit extension.
There's no "process explorer" kind of tool for Firefox; but there's https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Venkman with profiling mode, which you could use to see the time spent by chrome (meaning non-content, that is not web-page) scripts.
From what I've read about it, DTrace might also be useful for this sort of thing, but it requires creating a custom build and possibly adding additional probes to the source. I haven't played with it myself yet.