We Keep Coding

How to get title/url of tab while detecting tab change using JavaScript

Detecting Tab Change using javascript can be done easily using page visibility API as it is mentioned in this answer
Is there some way to get the information about the changed tab like the title of the tab/URL etc using javascript, jquery, or any other method?

For (obvious) security and privacy reasons this is not possible on any modern browser I am aware of.
But since you asked for any other methods, you could achieve this pretty easily with a browser addon and the tabs api.

Nope, Javascript interacts with web APIs that the browser has installed on it.
So in order to do this, there would have to be a way within one of the installed APIs to do this. Which I highly doubt there is. Also, Most browsers effectively run the DOM in a contained sandbox meaning that javascript and the web APIs can only access things from within its sandbox aka tab.
That said, it doesn't mean it's impossible. There may be an exploit in one of the API's allowing you to get other browsers info not usually available to you.
Feel free to crawl through all the web api docs to find an exploit and also try to engineer a way to break out of chromes tab sandboxing architecture via javascript.
I won't say it's impossible but it's highly unlikely unless someone makes a big mistake on a future release of chrome and one of the direct to browsers api's has an exploit. Sounds like a lottery win scenario to me just to read a tab.

What changes to be done for making the plugin work for chrome, as NPAPI support will be stopped by Sept 2015

Recently after the latest chrome update version 42, NPAPI support was disabled by default in Chrome thus effectively dropping support for Silverlight, Java, Facebook Video and other similar NPAPI based plugins.As per the chromium developer docs we can temporarily re-enable NPAPI by overriding via
chrome://flags/#enable-npapi(Enable NPAPI). However this option will be there only till Sept 2015.They have also mentioned that this wait is for mission-critical plugins to make transition.
We are using an enterprise plugin and we have some dependency on chrome , to make the transition we have to re-implement the plugin.
What are the things we need to do for re-implementing and make it work for chrome, guys please shade some light on this.

It really depends on what exactly your plugin needs to do; FireBreath 2 is nearly ready and supports plugins in Chrome via native messaging, however:
For Chrome you must install an extension as well as installing the binary (the binary installer can trigger the extension install, but must be confirmed by the user)
There is no direct drawing model, so you'd need to use a javascript layer to draw and access it from the plugin
All APIs of FireBreath 2 plugins are now asynchronous.
FireBreath 2 is not quite ready, though you're welcome to help us get it ready.
Other options include Native Client, which has much better drawing support but is sandboxed, and Emscripten which allows you to compile C++ to javascript and is shockingly fast, but is also of course sandboxed. You could also write your own native messaging host to do what you need.
As #smorgan says, there is no one solution that is a drop-in replacement.

There is no general-purpose replacement that can do everything NPAPI plugins could do, so without knowing what your plugin does there's no way to answer that question.
You should look at the last section of the deprecation guide, and see if your plugin fits into one of the categories there. If not, you should post a specific question about what you want to accomplish.

Differences between Node environment and browser javascript environment

I've always been a bit annoyed that there are two major realms of javascript projects -- Node and "the browser" -- and while most browser JS can be easily run inside Node with a couple libraries for DOM stuff if needed, porting Node stuff to the browser is usually an afterthought.
This all seems like a lot of wasted energy on the part of developer communities, which could be alleviated by all JS developers just developing for the "least common denominator" (the browser) and using various shims to use features only available in Node or other JS environments besides the plain old browser.
This would not only cut out a lot ecosystem cruft and make development-in-the-browser more realistic, it also makes it commonplace to give the browser superpowers…Look for example at browserver, which sets up an http server inside the browser, but because the browser cannot actually accept http requests, uses websockets to talk to a proxy Node server that can.
So I want to ask, what are the real technical constraints of a web browser's javascript environment versus Node?
I thought Node was just "a javascript environment, plus http server and local filesystem, minus the DOM and the chrome". Are there technical reasons why developers could not potentially move to the approach I described above, developing for the browser JS environment (does this have an official name?) and using shims for Node?

Code that runs on the client usually have very different goals from the code that runs on the server. However when it makes sense to use some libarary's features in both environments there are a lot of them that are defined using a universal AMD form which makes them platform independent (e.g. Q).
The major difference between both environments is that one is subject to rigorous security policies and restrictions (browser) while the other isin't. The browser is also an untrustable environment for security-related operations such as enforcing security permissions.
I'll also add #jfriend00 comment in here since I believe it's also very relevant a exposes other differences:
The biggest practical difference is that you have to design a browser
application to work in an installed base of existing browsers
including older versions (lowest common denominator). When deploying a
node application, you get to select the ONE version of node that you
want to develop for and deploy with. This allows node developers to
use the latest greatest features in node which won't be available
across the general browser population for years. #jfriend00
Projects like browserver are interesting and I am all for experimental development, but are they truly useful in practice? Libraries should be designed for the environment in which they are truly useful. There are no benefits in making all libraries available in both environments. Not only that it will generally result in an increased code complexity, some features will sometimes not be shimmable resulting in an inconsistent API between platforms.

Here are some of the differences between these two environments:
Node.js has built-in libraries for HTTP and socket communication with which it can create a web server and thus be a replacement for other types of servers such as. Apache or Nginx
Node.js does not have browser APIs related to DOM, CSS, performance, document, as well as all APIs associated with the "window" object. Precisely because of the lack of a window object, the global object was renamed "global".
Node.js has full access to the system like any other source application. This means it can read and write directly to or from the file system, it can also have unlimited network access, and it can execute software...
Since the development of JavaScript is moving very fast, browsers often lag behind the implementation of new features of JavaScript, so you need to use an older version of JavaScript in the Browser, but this does not apply to Node.js, you can use it all modern ES6-7-8-9 JavaScript if your version of Node.js supports it.
Although within ES6 there is a syntax for working with modules (import/export syntax), it has only recently been added to node.js as an experimental option. Node.js mainly uses CommonJS syntax to work with modules.

lean&fast way to make an addon work for all major browsers? firefox,chrome,[opera,internet explorer,safari]

Yet there are tools to make one addon for all major browsers at once,
see: crossrider, kangoextensions and http://besttoolbars.net/products/addon_framework
With greasemonkey and a converter to a full firefox addon,
i already made an addon, that does the following three simple things:
check http status of external links with wiki.greasespot.net/GM_xmlhttpRequest,
(which won't work out with javascript alone as of cross-site-scriting policy.)
manipulate the current page/dom through some regex
inject an additional hosted javascript for automatic updates
but is there any "cross-browser addon maker" capable of the 3 things above?
(especially http to external links like GM_xmlhttpRequest)
and open source, free or at least free of their branding in the addons made with it?
or else what is the easierst way from my greasemonkey script to full addons for also
chrome,[opera,internet explorer,safari(or more)].
(i imagine this alone could be a few kb of code to match the requirnments above and doesnt need to be a complex service like crossrider?)
Thanks!=)

I think you can achieve your goals using the Crossrider platform, writing code once in JavaScript that works on all supported platforms. For your specific goals, you can use the appAPI.request API for your HTTP requests and jQuery/JS DOM to manipulate the page content.
Regarding branding, the Crossrider platform enables you to customize the extension using your own image, specify your own post-installation landing page (Thank You page), and either host a seamless installer widget on your site OR host a Windows installer file, and hence an end user does not see any Crossrider branding at all.
Finally, regarding monetization, we have a strict policy of only monetizing extensions with the mutual consent of the extension developer.
I hope this clarifies your concerns, but please feel free to ask any further questions either on this thread or by contacting our support (support#crossrider.com).
Disclaimer: I am a Crossrider employee

Pluggable language engines for browsers. Why not?

Firefox has a SpiderMonkey javascript engine. Chrome has V8 javascript engine.
Obviously those engines are a separate products and browsers utilize some kind of interface API to interact with them.
On the other hand programmers longed for a long time for their favorite language in browser. So much so, that we have products like GWT (for java), parenscript (for common lisp), HJScript (for haskell), and i'm sure many other libraries for many other languages that allow programmers stay with their favorite language and generate client side code as well.
The idea is so obvious that i am surprised that there's no implementation of it yet. Why not publish the interface API of browser to language engine and allow web sites to provide custom language engines as downloadable bundles. With current internet speeds 3-4 megabytes one time download is not a problem for majority of applications, even more so for intranet usage.
So where's our pluggable engines ?

You don't need pluggable engines really, just an agreed upon byte-code format. Google is going down that path now with NaCl and PNaCl which is based on LLVM. So any program that compiled down to a safe subset of LLVM byte-code could be run in the browser.

Browser vendors can't even agree on a common video format (see the html5 <video> debate) or on how the document DOM object should look like, and you want them to agree on a whole language interface?
Good luck.

I guess you forgot about applets and embed's. Both offer exactly what you want. And both suck for the very same reason.

We've been down this route in the past.
Older versions of IE supported VBScript as a scripting language in addition to JScript.
The result was a whole load of sites that only worked in IE.
This isn't what the web needs again. As a developer, I may desperately want to write code using my favourite language, but as a user I want to be able to browse all sites on the web without having to worry about which plug-ins I need for any given site, or whether my preferred browser can even use those plug-ins.
This is the problem that Microsoft's Silverlight has had. It might be a marvellous technology, but to the end user, why do I want another plug-in? Silverlight has managed to gain some market share thanks to the sheer power of Microsoft, but really not that much.
Now, if the code reaching the end user is consistent, regardless of the language it's written in, then the language doesn't matter. But this effectively means compiled code (or at least bytecode), which is a whole different kettle of fish to running a scripting language in the browser.