How do I create an always-present sidebar in a Chrome browser extension? Do I have to inject something into each page the user views? That seems weird because it would disappear every time the user navigates to a new page. Also, I'd be worried about my code and HTML interfering with the page and I can't possibly test every page on the net to be sure it works everywhere.
It looks like there was an API for this that was just removed? Is this feature dead for good or are there any plans to bring it back?
You have to inject HTML into every page. There was an experimental Sidebar API for a while but it was never developed to state that the Chromium team was happy with. They are still keeping the issue open but it is not currently being developed. You should star the issue if you wish to get updates on it's progress.
Update:
The feature is removed and there is no further development on it.
Quoting from their site:
We will not be proceeding with this feature request. We recognize that there is a significant number of you who will be disappointed with this decision, evidenced in part by the many stars on this issue. We debated it extensively, both inside the team and with members of the community. In the end we decided that the WontFix resolution was more in keeping with Chrome's core value of simplicity.
Related
I have read several articles on feature detection and that it is more reliable than browser detection because browsers lie.
I couldn't find any information on why they lie. Does anyone know the reason why they would do that?
As far as I understand it, Webmasters do browser sniffing to find the capabilities of a browser and limit what they send to the browser. If a browser lies about it's capabilities they will receive more from the webmaster, you can read more:
http://farukat.es/journal/2011/02/499-lest-we-forget-or-how-i-learned-whats-so-bad-about-browser-sniffing
http://webaim.org/blog/user-agent-string-history/
The reason is simple:
Because web sites look at the user agent string and make assumptions about the browser, which are then invalid when the browser is updated to a new version.
This has been going on almost since the begining of the web. Browser vendors don't want their new versions to break the web, so they tweak the UA string to fool the code on existing sites.
Ultimately, if everyone used the UA string responsibly and updated their sites whenever new browser versions come out, then browsers wouldn't need to lie. But you have to admit, that's asking quite a lot.
Feature detection works better because when a new browser version comes out with that feature, the detection will pick it up automatically without the either browser needing to do anything special nor the site owner.
Of course, there are times when feature detection doesn't work perfectly -- eg maybe if a feature exists but has bugs in a particular browser. In that case, yes, you may want to do browser detection as a fall-back. But in most cases, feature detection is a much better option.
Another more modern reason is to just avoid demands to install mobile apps (where product owners contol what I can and can't do with content. No thanks!).
Today Reddit started to block viewing subreddits in case they detect a mobile browser in UserAgent so I had to change it just to be able to view content.
So if you are any sort of clg fan, you'll occasionally visit azubu.tv to watch them. If you go into the chat, using chrome, you can't change your text color. The reason is in line 689 of the chat js. (it's best to pop it out since it's in an iframe). There is an extra = in the comparison that works in firefox but not chrome.
I did not code this site. However, is there anyway to use a chrome plugin to permafix that function? I've already sent out a code update request to the admin -- a month ago. I've been just opening up the javascript console to do it manually but I'd like to help others.
I isn't expected people to develop extensions (or plugins) to fix web pages' .js, because it would take a lot of effort in reverse engineering and development, and the extension will become obsolete as soon the server administrator fixes his own js.
Extensions can do it, but are a very odd way to do that.
I don't know who voted you down without a comment; it's not the way we used to do it here.
I´m planning to make a full dynamic site using pjax, with static menu (only the content will be updated with pjax). How bad is this?
The site that i have planned to implat this on have a lots of data on it, most images.
I have tested my solution on my local machine and it seems to work but in production it will probably be slow or what do you guys think? Are this bad practise?
Now on pjax start i slide out my container to the left, and slide in the new content from the right. I have noticed a small performance lost when i do this in Safari and FireFox. Should i skip my solution and just do regular updates of the page? I want to do something like Twitters iPhone app, but on the web.
The reason i want to do this are that i have a full size google maps with a lot of pins that take some time to load.
I have found Tubrolinks (http://www.github.com/rails/turbolinks) that would be included in Rails 4.0, its great adn i think a good answer to my question.
So I have a Chrome extension which uses Google Analytics for tracking various things. One of those things is the extension version, set using a custom variable every time the background page is started. Now my question is: Which scope should I use, visitor or session level? I can't figure it out based on Google's documentation, and no one else seems to have had this issue. I'm not even sure there's any difference, or maybe it's just something like "it's bad practice to overwrite visitor level variables".
Chrome extensions are have some very specific characteristics and the answer to this question is not applicable to anything that is not a Chrome extension.
From your question I believe you do some basic tracking on your background page, but I assume you also do so on a popup or you fire an event if the user do some action with your extension.
In that case I'll strongly suggest that you use a Visitor Level Custom var.
The problem is that the background page is loaded only once, when the browser opens up, and it's like a tab that stays open and silent, possibly hosting some callback functions for events that may or may not happen.
Because of that once the visitor first loads your extension you'll see a pageview from you background page setting this custom var.
After that there may be a silent period where your extension doesn't track anything, this period can take hours, until hopefully the user interacts with your extensions and tracks additional data to analytics. When it finally happens chances are that over half an hour has passed since the backgroun page loaded. If that is true the visit (or session) that was started by the background page is already over. A visit with no activity for 30 min is closed by analytics. In that case that interaction will spawn a new visit.
If you set the Custom Var as a visit leve variable chances are that when you see interactions on the extension, these interactions won't have the custom var.
This approach has the bad side effect that if the version of your extension changes and the user doesn't reload the browser the version is not going to be updated, and it will be erroneously registered as te old version.
That's very unlikely. And the only way to fix it is to check the version of your app everytime the user does an interaction and set that custom var again. I believe that this is excessive and I don't do it in my extension. Still if you opt for it, it really doesn't matter if it's a visit level or visitor level custom var.
I was thinking to add meta tag always in all the websites.
That will trigger google chorme frame to load for users who already installed. I can see the benefits but is there any concerns or facts that I should know before I do that?
Testing in google chrome is enough or testing in google chrome frame explicitly required?
Thanks
Note: please do not mention current know problems "print" and "download" issue. I'm sure those will get fixed soon :)
The only argument against chrome frame that I have seen so far is Microsoft's - "Google Chrome Frame running as a plugin has doubled the attach area for malware and malicious scripts."
Also, you may run into problems with frames. If you have chrome frame on your page and someone has that page iframed on their site you may run into some problems. More info:
http://groups.google.com/group/google-chrome-frame/browse_thread/thread/d5ffe442658bc60e/e6d7a4c1c179c931?lnk=gst&q=iframe
You should only need to test in Chrome Frame for (X)HTML, CSS, and JavaScript...basic stuff. If you are using AJAX (while trying not to break the back button), worried about caching, cookies (accessed via javascript), or other potentially browser-specific browser interactions I suggest testing on the IE+CF platform...at least until the CF team announces 100% interoperability between CF and IE.
Check out the CF Google group for more issues.
Are there any concerns or facts you should know? Yes: Not everyone has Google Chrome Frame installed.
You are adding a new user agent that you will need to test and debug against, without removing the need to test and debug the user experience for other browsers (notably plain IE by itself).
If you don't make the IE user experience equivalent to the Google Chrome experience, then you are alienating a significant percentage of users. Depending on your website and its expected users, the impact of this may range from undesirable to unacceptable. If you do make the user experience equivalent, then there is no point in adding the meta tag.