I'm experiencing a bad behavior of Select2 on a chrome extension using AngularJS and Angular-UI.
The scenario
Select2's content is loaded asynchronously via AngularJs $resouces module.
What should happen?
The content should be display when i click on the Select2.
What is actually happening?
When i first click on any select2 dropdown, it just winks and then hides.
Obs.:
The same code works just fine out of chrome's extension popup.
You can see it working here: http://moneynow2.apphb.com.
And can browse the code here at my github repository.
Mine working fine in Chrome extension, but I'm getting "Refused to execute inline event handler because it violates the following Content Security Policy directive: "default-src 'self' chrome-extension-resource:". Note that 'script-src' was not explicitly set, so 'default-src' is used as a fallback." In chrome console.
This is really hard to test.
It looks like in a popup, when I open the dropmenu, the route gets reloaded (the whole controller and contents of ng-view reloads). This doesn't occur on the webpage. I thought that the popup was appearing in the bottom-right corner, stretching out the window (it happened as I stepped through it). When this occurred, I thought it might have triggered a window-scroll event which actually causes select2 to disappear (it's a feature of select2 to prevent the dropmenu from staying in some random place since it's pos:fixed).
I also don't know enough about chrome popups to figure out what events may cause the 'url' to change or a scroll event to trigger, etc.
At first I would have suggested doing selectOptions = { data: $myResource.query() } or something, but I'm starting to think it won't help.
Suggestion:
Try removing the router and see what happens. I don't really know that you should bother with it in a chrome extension. In such a small space, less code is probably better anyway.
Related
https://developer.chrome.com/extensions/optionsV2 tells me that I should be using options_ui in my manifest, rather than options_page, and recommends I start upgrading immediately.
However, I can't find any way to actually debug the script run by my options page when I use options_ui—the Options popup is in an tag, and the developer tools don't show me the source, or even the HTML content.
For now, I just comment out options_ui and let options_page take effect when I need to debug. I'm guessing that setting "options_ui": {"open_in_tab": true,...} would have the same effect, but it would be really nice to figure out how to actually debug the script when it's running the new way.
Auspex,
Teepeemm's comment is correct.
Other way, you can launch your options page from other tab using its full URL
like,
chrome-extension://{your extension id here}/{your options page path here, from the extension root}
e.g. say my extension id aaabbbcccdddeeefffggg, and say, my options page is located (from extension root) at app/html/options.html; then i can load up below URL in a new tab ---
chrome-extension://aaabbbcccdddeeefffggg/app/html/options.html
Now here, in this tab; you can do your regular debugging around HTML and javascript.
I hope this suffices your debugging requirement for 'new options UI' for chrome.
Teepeemm's comment is correct.
It's as simple as right-clicking inside the options page modal and selecting "Inspect element" - it will open the correct Dev Tools.
In manifest.json, we specify our background page and can put an html or a js file for it. Since it is only a script that executes what sense does it make to have an html file for it?
I mean where is UI going to get shown anyway?
Similarly the devtools_page property has to be an html file. What sense does that make?
It will not be shown anywhere (that's the essence of "background"), but some elements on it make sense.
You can have an <audio> tag, and if you play it, it will be heard.
You can have an <iframe> with some other page loaded invisibly.
..and so on
As for devtools_page, it would actually be visible in the interface (as an extra panel in the DevTools)
It is possible that devtools_page must be an HTML file just for legacy reasons: it was not updated when manifest version 2 rolled out with changes to how background pages are specified. Still, the same arguments as above apply.
background_page is a legacy feature from the initial support of extensions in Chrome. background.scripts was added in Chrome 18. I can't speak for Google's original intentions but I'd guess that in the original design using an page felt more natural and would be less likely to confuse developers. Once they realized how many background_pages were just being used to load JavaScript it made sense to explicitly support that.
I have a big SVG document here, containing a map of all the quests in a certain online game. Each quest node is inside a SVG <a> element, linking to a distinct named anchor in a big HTML document that loads in another tab, containing further details about that particular quest. This works exactly as desired in desktop Safari, and I'd expect it to work just as well in any browser that supports SVG at all since I'm using only the most basic form of linking, but it fails badly on Mobile Safari (iOS 6) - which is my single most important browser target, considering that the game in question is for the iPad. It only scrolls to the correct anchor on the initial load of the HTML page; clicking a different quest in the SVG tab will cause a switch to the HTML tab, and the hash (fragment ID) in the address bar changes, but the page doesn't auto-scroll.
This appears to be a known limitation in Mobile Safari - hash-only changes in the URL apparently used to force a page reload, and that got over-fixed such that nothing gets triggered at all now. The fixes I've found online all seem to be applicable only in cases where the URL change is being generated programatically, from within the same document, rather than static links from a different document.
Further details:
I've tried doing the named anchors in both the old <a name="..."> form, and the newer <h1 id="..."> form. No difference.
I've tried adding an onhashchange handler, to force the scrolling to take place, but the handler isn't being called at all (verified by putting an alert() in it).
I could presumably fix the problem by having each quest's details in a separate HTML file, but that would severely affect usability - with all the details in a single file, you can use your browser's Find feature to search through them all at once. (Also, deploying 1006 files to my web hosting after each update would be a bit of a pain...)
Anybody have an idea for a work-around?
I have been working on this site for some time and just launched it for a client.
People have actually had trouble beleiving I had done it on WordPress, though I don't see why...
Anyway, I suddenly see that the form fields of one of the forms on the site (Newsletter Registration) disappear while on IE, you get to see them for a second and puff, they're gone. I did check this previously on IE and it worked, I especially used CSS3 PIE to get the rounded effect for the fields on IE...
Link to website: http://www.doritsivan.com (hope this isn't considered promotion, not my intention)
site is based on WordPress and jQuery.
resolved the issue, thank you all. it was a bad case of relative vs. absolute positioning and the fields decided to go away (literaly)
A bunch of debugging with firebug-lite (btw was real to get it to work on my IE, kept on crashing or refusing to load altogether combined with IE popup and security issues) and I understoid that this was the issue, then some pixel fiddling and all was good. rechecked in Chrome, saw that result was exactly the same. job done
Google Chrome Extension documentation has some good information here:
http://code.google.com/chrome/extensions/tut_analytics.html
I put the analytics tracking code in my background.html file.
However I tried putting the _gaq.push call inside a script that runs on the page and got an error saying that the variable _gaq is not defined.
So I have to put onclick events in every element on the page I want to track and from there, call a function in background.html? Is there a better way to track events?
You can do this with chrome.extension.sendRequest in the content script and chrome.extension.onRequest.addListener in the background.html page. See here for more details: http://code.google.com/chrome/extensions/messaging.html. Also be sure your manifest.json is correct; I ran into problems when I had a hyphen character instead of an underscore.