I read this article https://wiki.mozilla.org/NPAPI:HttpOnlyCookies , since the article is almost two years old, has it been implemented in NPAPI or Firebreath
It's not listed as an accepted proposal on the main NPAPI page, so it's never become part of NPAPI. That's why it's not in the NPAPI headers. Given that, it's unlikely any browser implements it. Chromium certainly hasn't, and mxr doesn't show any indication of NPNURLVHttpOnlyCookie in Gecko either. (Not surprising, since both Chromium and Mozilla contributors argued against it on the NPAPI list when it was proposed.)
The age of the proposal is irrelevant given that it was not accepted.
Support is not available in FireBreath, though it could probably be added if you wanted. I think support has been added to Firefox's NPAPI, don't know about Chrome. You'd have to try it.
Related
What is the exact difference between plugins, add-on and extensions.
I have read a lot about this and confused,
For example see these four definitions:
1-fire-fox says "Add-ons is the collective name for extensions, themes and plugins" (see https://support.mozilla.org/en-US/questions/790919)
2-www.Differencebetween.net says "Plug-in and Add-on are simply extensions ... Plug-in is the term that is usually used when referring to third party software (interact with a certain program) like flash player ...
3- wikipedia (https://en.wikipedia.org/wiki/Plug-in_%28computing%29) says plugin are being deprecated.
4-I have read in another website that plugins are larger than add-ons and it consist add-on concept.
Also I have read the answer provided in firefox add-on vs. extensions vs. plugins and http://colonelpanic.net/2010/08/browser-plugins-vs-extensions-the-difference/
However I want to understand these differences especially in firebreath where plugins execute automatically through user's consent and add-on should install manually. Also I think plugin embed in htm page while add-on is in form of a separated file like xpi in fire-fox.
Any exact, comprehensive and precise definitions for these three concepts which emerge differences would be appreciated.
General rule of thumb:
Plugins
When you're talking about a web browser, a plugin talks about a NPAPI or similar plugin, which is specific to the page. IE doesn't support "plugins" per se, but they have activex controls which can fill a similar function, though there are also BHO (Browser Helper Object) ActiveX controls which are more similar to extensions. Thus we (the FireBreath team) usually use the term "plugin" to refer to something that works like a NPAPI plugin and the term "extension" to refer to something that works like a typical extension (firefox XPI, Chrome CRX, etc).
Plugins only know about the page they are in; they don't know anything else about the browser or what is loaded in other pages.
Plugins have been responsible for a lot of security problems, since they actually run native code. This has led to a lot of discrimination against them -- much of it deserved. Because of this, and because NPAPI is a royal pain in the neck (hence FireBreath was created), most browsers are trying to phase out plugins. Plugins should never be used unless there is no other way to solve your problem.
That said, there are a lot of cases where they are the only option.
Extensions
An extension is something that is specific to the browser, and they are a bit different on each browser, but tend to be able to learn more about the overall state of the browser; they may be automatically added to pages, accessible separately from a page, etc.
Add-ons
Add-on is more of a generic term which is used to mean a lot of different things. What it actually means just depends on who is talking, but the mozilla definition is probably as good as any; it could be anything that adds functionality to your web browser, regardless of the context.
Key Differences
Extensions tend to be automatic once installed. Plugins are instantiated in one of two ways: 1) by an <object> or <embed> tag in the HTML of a web page, or 2) because they are registered to be the handler for a mimetype which the browser doesn't support.
FireBreath
FireBreath deals with plugins. It has nothing to do with typical browser extensions, only plugins. It is a C++ framework, not a javascript framework, and it allows you to add functionality that can be used from within a web page. Typically FireBreath plugins are used from inside a <object> tag.
FireBreath post-NPAPI
As you may or may not know, Chrome has dropped support for NPAPI plugins (as of version 45) and Firefox has done so as of version 52 (excluding the version 52 Extended Support Release, which will support them for another year). FireBreath 2.0 is now being used in production by several companies and can produce "plugins" (not really plugins, but work similarly) which can work with Google Chrome and Firefox via Native Messaging via a helper extension. The main limitation is drawing; there is no way to draw directly to the browser across native messaging (well, no good way, and no way at all on platforms other than windows).
Eventually we may add support for some abstraction to draw using Canvas / WebGL over the native messaging bridge in FireBreath 2.0, but that hasn't been done yet. Frankly, I don't need it, so I haven't bothered to do it. FireBreath is an open source framework which has unfortunately not received enough support from users in the last couple of years and so the documentation is a bit outdated and there are a lot of little things which haven't been done.
The Native Messaging method relies on an Extension -- we did this primarily to confuse everyone, of course, but also because it was the only way to allow us to communicate with FireBreath plugins from the page in Google Chrome or Firefox.
*(Last updated Mar 6, 2017; Firefox 52 is scheduled to release tomorrow)
Hope that helps. See also:
Browser Plugins vs Extensions -- the difference
FireBreath 2.0 home page
I've recently started using watir-webdriver and so far am a big fan. However I need to be able to test Safari too, and I don't have access to a mac to be able to use Safari-Watir.
Does anyone know a good alternative to use for testing Safari on a windows machine? (In Ruby of course)
Thanks
(important, see UPDATE below)
the Selenium Webdriver folks are apparently waiting for something from Apple in order to support safari. I would not hold your breath.
Apple does have a version of Safari for the PC, I'm not sure how good the current version is, the initial releases were.. um, well, lets just say they had issues (lots of issues)
Personally (mostly for security reasons) I would not run it nor recommend anyone use it for any purpose other than downloading Chrome or Firefox. But unfortunately a lot of apple users use it because it's what came with their systems, which means to the extent apple users are part of your target market, you have to test on it.
For the moment that means you'll need to use Safariwatir, which has not as far as I can tell had an update for a year or more.
the current state of support on both the Selenium/Webdriver side and the Safariwatir side was discussed recently in this thread in the watir general group on google
UPDATE
Webdriver now has Safari support, which makes direct support of safari (I think on a mac only at this point) possible. See http://watirmelon.com/2012/04/17/using-watir-webdriver-with-safari-at-last/ for more info.. still a bit DYI but I'm sure it will get more accessable soon.
Mike, seems this is available now. Alister Scott wrote up some instructions on his blog Using Watir-Webdriver with Safari At Last
Unfortunately this still a bit DYI because you have to build your own safari extension, which requires getting certificates and such from apple, and I'm not sure if you can create the right environment to build that stuff on anything other than a mac.
The question's pretty straightforward and the old topic is here. I'm hoping to get up-to-date answers since IE9's gonna be released this March 14, 2011.
In addition, I would also like to ask when will Firefox and Opera be supporting WebSockets?
I've been following both the development of IE9 and I also participate in the HyBi WG (WebSockets protocol). Microsoft has been keeping the demo implementation of WebSockets up to date with the latest revisions of the protocol, however, I suspect that the initial release of IE9 will not have built-in WebSockets support. It will probably not be until IE10 unless they start to see it as a big competitive disadvantage in which case we will likely see it added in a IE9 update before IE10.
Firefox will likely support WebSockets in an update to FF4 or with FF5 (but the plan is that 5 will come out this year). Also, you can turn on the current implementation in FF4 using a about:config option.
I have no idea about Opera. They are interesting in the protocol but they've been pretty silent on the HyBi list.
Also, if you need WebSockets right now you can always use the Flash shim/fallback web-socket-js.
Update:
I forgot, Opera 11.00 does have WebSockets support built-in but disabled. Go to opera:config and search for WebSocket.
So in summary, just about every modern browser has WebSockets support in some way either built-in and enabled (Chrome, Safari, iOS), built-in but disabled (FF4 and Opera), as a downloadable add-on (IE9), or using the web-socket-js Flash emulator (everything except iOS).
Nope, The RTW version of IE9 does NOT support a websocket type... :(
UPDATE: The IE team is developing websockets for their browser, but it's not included in the initial release because the standard is in a fluid state. Although the implementation is stable, the standard isn't. If you want to test it out in IE9, you can by downloading it here:
http://html5labs.interoperabilitybridges.com/
You can hear more about it by listening to this DotNetRocks podcast:
http://www.dotnetrocks.com/default.aspx?showNum=648
Best regards.
IE9 does support WebSockets but not as a "built-in" functionality. You have to download it as a plugin from http://html5labs.interoperabilitybridges.com
The reason given by microsoft for not including in default setup is - the standard is unstable and keeps changing and in default setup only stable HTML5 standards shall be included.
So in a way IE10 as of now will also not include.
The HTML5Labs site will provide "experimental" support to unstable standards.
I want to develop Safari plugin using xCode, What API should I use? Someone can give me some documents or sample codes ,Thanks very much!
The answer is rather complicated i'm afraid.
Unfortunately, Safari the web browser does not have a plugin API. That means you technically cannot extend Safari's user interface or features using plugins.
However, WebKit the web rendering engine (which powers Safari and many other browsers/apps) does have a plugin API (actually it has 2) which allows you to create plugins for rendering web content inside webkit webviews.
You can find documentation on developing WebKit plugins in Apple's docs here. (PDF Link!)
Also note: Safari's lack of a true plugin API has not stopped lots of developers from developing various pieces of software which they call "Safari plugins" even tho they are technically not Safari plugins. They are usually something called an "Input Manager" which are widely viewed as rather questionable pieces of software. Input Managers always seem to be on the cusp of becoming unsupported or broken by Apple. It's not really clear whether Input Managers are kosher with Apple or not.
Then again, several "Safari plugin" Input Managers are quite popular, so....
Input Managers are a whole other topic. I'm sure if you google it you can find a lot of information on them. However, personally I would advise against developing an Input Manager due to their questionable status in the Mac software world and their constant danger of becoming unsupported or badly broken.
Update: A few years after I originally answered this question, Apple did provide a sort of plug-in API for the Safari browser itself. However, they are called "Extensions", not plug-ins.
See the Apple Safari Extension Programming Guide for details.
Check out Rentzsch's ClickToFlash, it's a plug-in that is fairly well documented, along with neat source code.
Many of the upcoming generation of browsers (FF 3.1, IE8) are going to support cross-domain XMLHttpRequests in one fashion or other (with security concerns, as long as the server opts in, etc).
Is the same bit of functionality going to be in WebKit?
FF: https://developer.mozilla.org/en/Cross-Site_XMLHttpRequest
IE: http://blogs.msdn.com/ie/archive/2008/06/23/securing-cross-site-xmlhttprequest.aspx
Basic support for this was added to WebKit in May (see this patch). There are have been a number of other patches since then cleaning it up and refactoring bits of WebKit to deal with the changes entailed as well as tracking changes to the spec. Since the spec had changes recently (and webkit was updated with them 3 days ago) I think it is safe to assume no currently shipping browsers support it, but that most of them will in the future, and the current WebKit nightlies are tracking the standard fairly closely.
I think this is really up to the standard (http://www.w3.org/TR/XMLHttpRequest/) rather than the browsers framework, or javascript engine.
In fact I fully disagree with Microsofts decision to implement their own stuff that has nothing to do with the W3C standard. The web is a mess today mostly because of Microsofts ugly implementation of things.
As per WebKit, they seem to be pretty up-to-date with W3C.
Here's also a good article about this: http://ajaxian.com/archives/the-fight-for-cross-domain-xmlhttprequest
If you're looking for other ways to communicate cross-domain using ajax style (without using the XMLHttpRequest object), you should check out JSONP, it is currently fully supported on all browsers.