With Firefox discontinuing the use XUL overlay it raises concerns that Selenium IDE requires this overlay to function. Can anyone confirm one way or the other?
Mozilla Will Deprecate XUL Add-ons Before the End of 2017
Selenium IDE is definitely an overlay/XUL based add-on. It contains an instal.rdf file and chrome.manifest file which uses the overlay directive.
Mozilla has stated that all types of extensions, other than WebExtensions, will be disabled in the near future. They have stated that the target for this is the 2017-11-14 release of Firefox 57. This deprecation may include complete themes, which they have stated "we will provide more details on what’s coming for themes very soon". That XUL based extensions would be deprecated was announced on 2015-08-15. The fact that they would be disabled in Firefox 57 (late 2017) was announced on 2016-11-23.
Mozilla has previously stated that such add-ons will not be explicitly disabled in Firefox Developer Edition and Nightly. However, a primary reason for deprecating such add-ons is that Mozilla wants the freedom to change the underlying Firefox code without worrying about add-on compatibility, other than WebExtensions. Thus, Firefox may change such that the features such add-ons rely upon are no longer available. Another alternative would be to use an Extended Service Release (ESR) version of Firefox. Firefox ESR 52 will be the current ESR at that time. My answer to "How to develop legacy Firefox add-ons in the future?" has more detail about possible options for continuing to use legacy add-ons.
I have not seen anything from Selenium IDE describing their plans for this change.
Related
Say I wanted to support IE11 (and sadly, I do), how would I go about making gatsby develop work on that poor old browser?
Right now, I get this message:
webpack-hot-middleware's client requires EventSource to work.
This polyfill looks promising, but that's as far as I've made it.
Any help?
P.S. Probably worth mentioning that I'm using Gatsby v 2.4.7
Looks like Gatsby doesn't support IE in development, only in production, so no polyfills will be added and IE will error when using gatsby develop.
https://www.gatsbyjs.org/packages/babel-preset-gatsby/
Can confirm on my project that running gatsby develop doesn't make it work for IE11, but using gatsby build does. When running gatsby develop, all I could see on IE11 is a blank page.
As per the documentation of Gatsby, You need to use babel 7.
Babel helps ensure the JavaScript you write works across different browsers (including older versions of Internet Explorer).
Reference:
Babel 7 (Gatsby)
Gatsby leverages Babel 7’s ability to automatically add polyfills for your target browsers.
Newer browsers support more JavaScript APIs than older browsers. For older versions, Gatsby (via Babel) automatically adds the minimum “polyfills” necessary for your code to work in those browsers.
If you start using a newer JavaScript API like [].includes that isn’t supported by some of your targeted browsers, you won’t have to worry about it breaking the older browsers as Babel will automatically add the needed polyfill core-js/modules/es7.array.includes.
Reference:
Browser Support
Right now, we're dealing with bugs in our web app that only seem to be occurring when IE10 is in Metro mode. When IE is run from the desktop the errors do not occur.
Questions:
When IE10 is in Metro mode, is it effectively a different browser version than when it's run from the desktop? Would this explain some of the behavioral differences we're seeing?
If it is a different version, is there a resource that explains the differences?
Specifically worried about rendering engine differences or JavaScript versions.
Yes, there are two different versions of IE10: Metro/Windows UI and the desktop version. Here is the official documentation from Microsoft that explains the similarities and differences: http://msdn.microsoft.com/library/ie/hh771832.aspx
I'm trying to install Fireshot addon in opera version 11.62. bt it is not available on opera. Actually fireshot is the extension use for taking screenshot of the current locating site so to make report on the site. so is their any option beside that or can i install Fireshot on it?
Fireshot is a Firefox extension, I don't believe it's available as an Opera extension. You could try installing Lightshot, which sounds like it tries to do something similar (though some of the comments make it sound like it's a bit dodgy), or one of many third-party apps like Screenshot Captor.
Right now it is NOT possible for an Opera extension to do it, though we are working on exposing such functionality in the future through extensions.
With the new firefox we are shipping more and more libraries as the XPom interfaces we interact with are changing. We are at 10 dlls and increasing, each with a size of almost 2M.
This size is a concern for some users.
While we look at restructuring the library to seperate the parts we can make common between them, we are thinking about how we might reduce space on the disk while supporting version upgrades.
For instance, user has FireFox 3.6 and 4.0 installed and when our product is installed we install a dll for each version. When Firefox is 4.0 upgraded (say to 6.0) how might we now install from the msi the missing dll for 6.0 support.
Any ideas on how we could achieve this?
Are we worrying for no reason?
My first thought was we 'AllowAdvertise' and when FF tries to load the dll as directed by chrome it will cause the install, it doesn't seem to work.
My first reaction is to suggest that you move away from XPCOM and towards js-ctypes. After all, this is the direction that Mozilla is pushing extension developers (see Wladimir Palant's comments for example). If there isn't anything in your binary code that absolutely positively requires use of XPCOM, you'll be much happier to ship a DLL that interfaces with JS when needed via js-ctypes.
I guess that your extension is Windows-only so supporting multiple platforms is not an issue. A possible short-term solution:
Have a separate extension package for each Firefox version, mark it as compatible with this Firefox version only (e.g. minVersion 4.0 and maxVersion 4.*).
When your extension is installed, install the version that is compatible with user's installed Firefox version.
Make sure that your extensions have an updateURL entry that is pointing to your server. It is important to have %APP_VERSION% in the URL.
Make sure to test Firefox betas and prepare a new extension version in time for the next Firefox release (releases are scheduled on Tuesdays every 6 weeks, next release being on September 27th).
Configure your server to indicate different packages as updates depending on the Firefox version used. So an update check with %APP_VERSION% 4.0.1 would be sent to extension-ff4.xpi while %APP_VERSION% 6.0 would get extension-ff6.xpi.
Firefox will always check for extension updates when the application is updated. If you can give it a compatible update it will install it. But preparing new packages every six weeks requires tons of effort and I guess that you want to refactor your code/move to js-ctypes ASAP. Oh, and I think that you need to ignore the unlikely scenario that some user has more than one Firefox version installed.
I know what the projects are about: Safari is Apples browser. WebKit is the engine used in Safari (and in many other browsers) which is open source. The WebKit source code contains also code to compile it as a standalone application. You can download the nightly build of WebKit here: http://nightly.webkit.org/
I have compared some of those nightly builds of WebKit to the official Safari application. And besides the slightly different logo and the different name, I haven't really seen any difference.
Are there any? Or is it just the branding?
Edit: I just tried again with the current nightly build of today and it even names itself "Safari" now.
The WebKit nightly builds only contain changes in the render engine, but don't change the UI at all. If you install the WebKit nightly build you get a newer version of the WebKit render engine, which is faster and more advanced as the older WebKit render engine shipped with Apple's Safari. For example if you visite www.html5test.com with Safari and the WebKit nightly build, you'll see that the WebKit nightly build scores more points because it has newest version of WebKit and therefor has even more advanced html5/css3 etc. support than the WebKit build used in Safari.
The UI that is used in the WebKit nightly builds is exactly the same as in the current version of Safari. As the UI is not part of the WebKit render engine, no changes are made to it by the WebKit devs. The browser vendors (Google, Apple etc.) build and publish the UI.