I have an extension which runs on a background page, the browserAction icon requires 2 clicks at max few seconds apart for the extension to start running background.js so I tried to see what's the issue, with chrome://extensions page loaded which states for my extension:Background page inactive. When I click one time the state changes to background page active and then the next click actually runs the extension, I couldn't see what's the issue, I use chrome.runtime.reload() at a couple of places, maybe that's the issue but what's the solution?
Thanks in advance
A background page can become inactive if it's declared as an Event page ( "persistent": false in the manifest).
Which probably means that you haven't set it up correctly if events are only handled after causing them twice.
Obvious solution: drop "persistent": false from the manifest. This is not recommended unless you use things that cannot work with Event pages (currently, mainly webRequest API)
Proper solution: see if your background script can be made into a proper Event page.
Related
When a site gets stuck in chrome with the 'loading www.site.com' status, Is there anyway to know which of the elements on the DOM is delaying the load? for example, it can be an external js file or image that is taking long time to load. I tried using the network tab in the DeveloperTools, but it only shows the elements already loaded and the time they took. I couldn't find a way to see which element is stuck.
I found a way that I'm not sure it works in all cases, but it did for me. I used the Timeline tab (now shown in the Performance tab), it's one of the tabs in Chrome Dev Tools.
Open Chrome Developer tools (F12 or CMD + Alt + I in Mac) and click the Performance tab
Make sure you drag the grey timeline bar all the way to the right, you want to see the most recent section of events so you can find what's getting stuck:
Check just down below the records sidebar. If you don't see this like in the capture below, try toggling the icons, there are different view modes. Now, going all the way down I found these. It doesn't look like that's going well. Obviously some kind of infinite loop in some random code:
I couldn't find out if it was an extension itself or some other bit of code. Clicking through I only could find // Copyright 2014 The Chromium Authors. All rights reserved..
Checking in Incognito mode clear of extensions, the website loads just fine.
I'd also advise to check the Console tab to see if there are were any errors that might cause the infinite loading thing. You'll often find clues there.
Got an odd problem, only persistent in Chrome browser. Can't imagine what would be the problem. Chrome's "Back" button doesn't work, nor does history.go(-1), but works fine on all other browsers. To see the problem simply click this link, which will asynchronously initiate searches on two separate services, or sites if you will. Upon click on any search result list item, we traverse to another page, but "Back" doesn't work for Chrome.
http://vps-net.com/MSSMine/?search=some
Any suggestions or ideas are welcome.
I found the problem with the page you have linked, I don't believe it to be an issue with Chrome.
When you load the page, it also loads two iFrames as the request to the site finishes. Chrome takes a somewhat different approach to history, allowing you to navigate not simply from changes in the URL displayed, but through every new individual browser-initiated request. When the iFrames load, Chrome adds history for each step of the page loading process, creating 4 separate history items. When you go back 1 "page load", it takes you back to the site you linked to, at a different step in the process. You aren't seeing anything change because as soon as that page loads, any unloaded iFrame now loads again.
If you do history.go(-8) or some other large number, you should see the page at that many pageloads ago. However, if the link is opened "in a new tab" then the history begins for that tab at the URL you told it to open, effectively limiting the history to the pages that occurred during that tab's lifespan.
This was tested on Chrome 34.0.1847.116 running under Ubuntu 13.10.
My back button was not working as well, but it would not work with any browser. I went into my add/delete software and deleted what software was added the night before - BOOM! All is fine now.
After messing around with Chrome Extension I noticed that when you are on the chrome://extensions page a background script initiated in the manifest file will run where as if you are just browsing the internet or on another other page besides the extension page the background script will not run.
Here is what I mean:
In my Manifest file:
"background": {
"scripts": ["jquery-latest.js","background.js"]
},
Now in the background.js file:
$(document).ready(function(){
alert("working");
});
I use a simple alert function to see if this will work and found out that alert("working"); only gets displayed when I am on the chrome://extension directory. If I go to google.com or something of that sort, no cigar.
My question lies in, why does this happen? How do I change it so it does alert no matter what.
The background script should be viewed as "running in the background of the Chrome browser".
Your desired effect (running a script for every page) is actually a task for content scripts.
To learn more, read https://developer.chrome.com/extensions/overview.html#arch.
It is because you are using the background page .. use the event page instead by slightly modifying the manifest.json..
Try adding this:
"background": {
"scripts": ["jquery-latest.js","background.js"],
"persistent": false
},
for more details on event pages check this : https://developer.chrome.com/extensions/event_pages
The effect is produced because whenever you load chrome://extensions it forces the extensions to reload, the same behavior can be reproduced using CTRL+R. So every time, the background page got a fresh reload, which doesn't happen in case of other pages.
The background script is a script running in the background to handle majority of chrome events that content scripts cannot. Content scripts are purely the content of the each page. Both cannot speak to each other, however, you can give the scripts listeners (e.g. chrome.browserAction.addListener(myFunction) plays the function when the button in the top right of your screen for the extension is clicked) order to find out whether a button has been pressed or even send a message from the background script into the page's console.
https://youtu.be/ew9ut7ixIlI
This video was a great introduction for me about background scripts, however, the part where he begins to talk about the listeners and such is 6:30.
I am trying to understand how to get from the chrome debugger the following info : there is an event on page triggered by a click on an input file type tag. But it is impossible for me to trace back the mecanism : which js file is called when the event is triggered. Is there a way do get this info from the debugger ?
Do you have a look at the Event Listeners entry in the right-hand window? If I right-click the 'Google-Chrome' tag at the bottom of your post, and select Inspect Element, I get the html tag highlighted. If I then look in the right-hand pane at the Event Listeners, I can see that this element has handlers for blur, click, keyup, keydown, mousedown, mouseout, mouseover. Yet just looking at the html I can't see that. If I expand the event handlers, I can see that they all point to "jquery.min.js : 3". This is because the file has been minimized and is only 4 lines - each of which is probably 20 or 25,000 chars long. Minimized scripts are difficult to analyse unfortunately.
Try it with a page that doesn't use minimizes scripts and you can click the link in the event handler window to be taken directly to the pertinant function - unfortunately, you are taken to the start of the line concerned, which makes jquery.min.js a waste of time to do this with. You can always use the non-minified version of a script for debugging purposes, switching over to the minified version for production.
With other's pages, you can sometimes get away with saving a local copy, before linking an unminified version of the script.
I've been working on a new website and practicing my JS/jQuery/AJaxy skills. Last night I wanted to take a look at how long the page was taking to render and see if there were any areas I could clean up to increase speed. While the page loads in about 200 - 300 ms every time, I'm seeing a large amount of blank space between resource loads under the network inspector.
http://i.imgur.com/7ng6m.jpg
Has anyone else seen this or know what I can do to minimize that time (talking about the blank space between like the html and the first css file)?
Quite possibly it is caused by the extensions you have installed. AdBlock, LastPass and Google quick scroll took altogether about 200 ms on my machine.
Unfortunately, these extensions are invoked on every site and block loading the additional resources.
Try it with out of the box browser setup, the loading time will increase tremendously.
You've got a bunch of images loaded just after the page has been loaded (the load and DOMContentLoaded events have fired - the blue and red vertical lines across the Timeline). I can see that the images are loaded by the JQuery library (the Initiator column), perhaps to build a gallery or something.
So, the case is that JQuery loads the images after the page load, presumably in the onload handler (this can look like $(document).ready(handler) in your code, but other options are possible, too).
The delay between the initial page load and requesting the first resources is almost certainly caused by Chrome extensions. To find the culprit: Record a timeline in the Timeline tab in Chrome Developer Tools; Identify the scripts that are running during the Parse HTML phase; Work out which extensions they're from.
To record a timeline:
Open the timeline tab and click record.
Reload the page and then stop the recording. (A couple of seconds should be enough.)
To find the culprit:
Find the first main Parse HTML block on the timeline. On the row below you will probably see one or more Evaluate Script blocks. These are the culprits.
Click on one of the Evaluate Script blocks and find the script name in the bottom pane. Mouse-over the script name. The tooltip will have the URL of the script, which should be of the form chrome-extension://{long_identifier}/{path}
Memorise the first few letters of the identifier and search for it in the chrome://extensions/ page. This tells you which extension is causing the problem. Try disabling it - you should see a difference.
Repeat for the other Evaluate Script blocks.
In my case, I have 20 extensions installed but only two were causing a delay: LastPass and Fauxbar. I've chosen to leave them enabled because for me the productivity benefit of these extensions outweighs the downside of the added latency.