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
Related
Im looking for some alternatives for Coded UI test. Unfortunately I'm only running Visual Studio 2013 professional
I have already looked at Selenium for Firefox, but that does not seem to work in my version of Firefox
If you want to test web applications, you can use any of the following:
Selenium
Cypress.io
Nightwatch.js(uses Selenium BTS)
For Windows desktop applications, Microsoft is now supporting Appium based WinAppDriver. For more details, you may check the GitHub repository here. I also teach a Udemy course on the subject which can be seen hereenter link description here.
White is another desktop application testing API but I haven't used it a lot.
We previously used WebAii to test a complex ASP.NET application and it was successful. I have found out that it is now part of Telerik controls. (I have no affiliation with the company.)
http://www.telerik.com/videos/details/teststudio/webaii-testing-framework-and-nunit
Other than that, keeping the UI as light/dummy as possible and testing beneath it extensively usually worked out better for me.
I work for a software development company that develops a certain application across multiple platforms: Web App, iOS, Android, Mac and Windows. We are looking for a way to do black box automated testing across all these platforms in an easily maintainable way.
So far it seems that Watir (watir.com) will be the best solution for the Web app (I prefer to use Ruby), while MonkeyTalk (www.gorillalogic.com/ testing-tools/monkeytalk) may be the best for our Mobile platforms (because we can write one set of tests for both platforms at the same time). We still have not been able to find a good solution for our desktop platforms.
We're a startup so we don't have the budget for a proprietary solution and those are looking for open source solutions.
Is there a better way to tackle the situation we're in and are there any better solutions for the various platforms we want to test.
You could use cucumber as the main test framework for all platforms (that would allow you to have the same scenarios and tests across all platforms) and use specific tools to exercise the native applications.
You could use cucumber + selenium web driver for your Web App, calabash for Android and iOS (http://github.com/calabash), frank for Mac apps (https://github.com/moredip/Frank). There is probably something for Windows as well to work with cucumber, but I personally don't know about it.
All of these tools would be free.
I have recently been browsing frameworks such as JavaScriptMVC, qooxdoo, Sproutcore and others alike which are using javascript to create desktop-like apps in the browser with minimal, or none css/html (depending on the framework).
What I know of titanium is that it uses html/css for the views, and language of choice (javascript, ruby,python,php) for everything else. Then it gets compiled(?) into a native app.
What are the quirks? if any?
Is it necessary for the user to install some sort of a runtime to execute the compiled app?
I suppose javascript is the prefered language, but how are the other ones handled?
For example, which Ruby interpreter would be included, would I be albe to use the ruby stdlib or external libraries? Would it affect the speed of the app? I.e JS > Ruby in terms of speed.
Since the views are CSS/HTML, would it still be necessary to style the elements, add them effects via JS librarier to achieve a widget-like feeling? Or does it come with some pre-made settings/classes for that?
I am not sure if it applies to the desktop package, but is there some syncing with the appcelerator's server required? What would it be necessary for?
I am sorry if the questions sound stupid, but I didn't even realise there are than many tools until recent. I am ultimately looking for something which is easy to use, has an option to work with a back-end server for data exchange, looks preferably good 'out of the box' or doesnt require that much work to get it themed nicely and works on mobile as well as desktop devices.
With Titanium you build your app out using javascript. Titanium ultimately generates its own XCode project for you that is compiled and deployed to a device.
The user does not require any runtime be installed prior to installing your app.
Unless your building custom modules to hook up your own controls you stick with javascript.
Your javascript calls end up as native controls, early versions required css like styling due to reliance on webkit but this is no longer the case.
There is no IDE but it does come with an app to create Titanium projects, test in emulator, deploy etc. It also talks back to HQ for updates.
In answer to (2), Titanium Mobile is Javascript only, but Desktop also supports Python, Perl and PHP.
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.
I have an old NPAPI plugin for OS X that I'm trying to refit for use with Snow Leopard's version of Safari. My problem is that when I switch Safari to 64-bit mode, it changes the plugin environment to out of process mode (where plugins are hosted by a 32-bit WebKitPluginHost process). And now my toolbar palettes are not visible on screen, even though the NSPanels on which they are based think they are visible. The documentation says that bringing up windows is not recommended, but doesn't say its prohibited; is there something I can do to bring up my Windows?
The most reliable solution is to simply let another application, possibly connected to your plugin via some IPC mechanism, do thatApple:
Avoid creating windows. The intent is for plug-ins to operate within the browser window. Although some plug-ins have historically done so, creating windows in your plug-in is not recommended. If you need to maintain separate windows, you should consider starting a separate application.
Bringing up windows from a plugin might work in some circumstances and completely break in different ones. By recommending against doing so Apple is at liberty to break your previously working behaviour whenever it wishes to.
Unfortunately, probably not. If you're doing anything that is not possible using the normal graphics libraries (CoreAnimation, Cocoa, etc), you probably can't do it using the 32 bit plugin in 64 bit safari.
You might be able to do more if you compile your plugin in 64 bit mode, though. I don't know :-/
I know I am a little late. Safari doesn't allow plugin to display NSPanel. You should try using NSWindow instead. I know Apple doesn't agree.
For showing menu you could use "popupcontextmenu". It takes NPNSMenu which is NSMenu typecasted.