Whenever I call FileUpload.Set, IE8 will open up the file browser window and just sit there without typing any text. This is on Windows XP and it used to work just fine until I upgraded from Ie7 to IE8. Anyone else run into this?
Turns out this line in the WatiN source was the problem:
if (Process.GetProcessById(window.ProcessID).ProcessName != "iexplore") return;
For some reason, the iexplore process on this machine appears as "IEXPLORE", in all caps. Adding a .ToLower() to the process name fixes the problem.
edit: looks like this bug has already been reported.
Because of the way WatiN looks for the dialog box (by style number), it's understandable that IE8 would be broken in versions less than 2.0. You may want to try it with the 2.0 beta.
Alternatively, you can dive the style numbers on the FileUpload DialogHandler and add the style numbers for IE7 and 8 (96CC20C4 and 96CC02C4).
I'd like to post an update for this problem since it came up again in Win7 OS.
If you have the same problem in the latest WatiN release you can override the function CanHandleDialog in the FileUploadDialogHandler class:
public override bool CanHandleDialog(Window window, System.IntPtr mainWindowHwnd)
{
return true;
}
It's not a clean solution but it is the simple and works.
Related
I am using Cordova 4.0.0 with AngularJS 1.2.26, Angular-Bootstrap 0.11.2, and UI Router 0.2.11 to create apps for Android and Windows (8.0 and 8.1). I am having an issue only when running the application in Windows with ui-bootstrap templates. The same error keeps popping up for standard templates for typeahead, datepicker, and the modal dialog, "Template for directive { whatever } must have exactly one root element."
Looking at the DOM inspector within Visual Studio, it seems that every node that has the ui-view directive is getting populated with its own set of head and body tags (which wraps around the template in question). I'm guessing that this is the issue, but am having trouble pinning down where these extra nodes are being inserted, and thus, having trouble proving out the theory.
The same code works as desired in the latest Chrome, FireFox, and IE desktop browsers, as well as within Android.
Does anyone have any insight on this behavior? It might also be worthwhile to note that ngCsp is being used to alleviate dyanmic content insertion restrictions on Metro applications.
Thanks in advance!
I found that the problem was in the shim winstore-jscompat.js
The method used to add the new tags has a bug.
My version of that method is:
cleansePropertySetter("innerHTML", function (propertyDescriptor, target, elements) {
empty(target);
for (var elementIndex = 0, elementsLength = elements.length; elementIndex < elementsLength; elementIndex++) {
if (elements[elementIndex].nodeName == 'BODY') {
for (var childIndex = 0, amountOfChildren = elements[elementIndex].childNodes.length; childIndex < amountOfChildren; childIndex++) {
target.appendChild(elements[elementIndex].childNodes[0]);
}
}
}
});
This did the trick for me. I have not yet tested all variations of directives.
The fix above didn't work for me, but I found a Fork that fixes the issue:
https://github.com/ClemMakesApps/winstore-jscompat/blob/master/winstore-jscompat.js
Note that this will probably be pulled into the main project at some point so this issue should go away "soon".
Also here is the original issue:
https://github.com/MSOpenTech/winstore-jscompat/issues/8
I'm trying to use Window.Location.Href in my VBScript code,
this throws me an error on Windows 7, IE 10:
Object doesn't support this property or method
It's working on XP and it's even working on Win7 if I'm using javascript.
What can be the problem?
Change to window.location.href (javascript sintax, no uppercase) and it will work.
It looks like Windows 7 IE 10 has some problems with VBScript. Can you try running your page in IE9 compatibility mode? If not then try to determine which object/property combination is giving you the problem. If Window.Location is the problem then try just using Location. However, if Location.Href is the problem then there may be a security issue going on.
More information on setting compatibility mode at vbscript is not working on IE10 browser mode
Like the title says, we are using ABCPdf6 to render PDFs from XSLT. Everything was working fine, but now we are getting an error that states "HTML render is blank". Using a browser (tested on IE/Firefox/Chrome) I am able to browse to the generated HTML (formatted XSL) and it displays perfectly fine in the browser. ABCPDF6 is not able to convert the file. I have tried giving control to the page that outputs the XSL, but I am still getting this error.
Does anyone have experience with ABCPdf and have encountered this before? The code was working fine before without a problem, and another page that uses the exact same generating code (even pointing to the same placeholder page that spits out the HTML!) is working fine.
I know what the problem was in my case now.
When i ran Windows update on my 2008 server, Internet Explorer 9 was installed.
IE 9 has a different way of rendering HTML which brakes abcPDF.
Updating to the latest version (8) solved all my problems. In this version you can also try another HTML engine called Gecko.
Even though you have resolved your problem, if anyone else gets this error, I would suggest that you install the trial version and try this out with the latest version.
I had same error on windows 7 machine with AbcPdf4.0. During MS updates IE8 was upgraded to IE10. Issue got fixed by uninstalling IE10.
Note: Abcpdf4.0 does not work with IE9 onwards. Either upgrade Abcpdf or uninstall latest IE.
I had a similar issue this morning with AbcPdf9. I added code to test the engine types and GECKO worked, then I swapped it back to MSHTML, and it still worked. So it was a temporary issue.
This is how you specify the engine type:
using (var document = new Doc())
{
document.HtmlOptions.Engine = EngineType.Gecko;
...
...
}
This code calls the method that converts the html to PDF, but calls it twice if necessary, since it will only fail once:
try
{
return GeneratePdfFromHtml(html, width, EngineType.MSHtml);
}
catch (Exception ex)
{
/* detect this known issue, swapping the rendering engine once seems to fix it */
if (ex.Message.ToUpper().Contains("BLANK"))
{
return GeneratePdfFromHtml(html, width, EngineType.Gecko);
}
throw;
}
Then you can add a parameter to the method that does the conversion:
public byte[] GeneratePdfFromHtml(string html, int width, EngineType engineType)
{
if (string.IsNullOrWhiteSpace(html)) throw new ArgumentNullException("html");
if (width < 100) throw new ArgumentOutOfRangeException("width");
try
{
using (var document = new Doc())
{
document.HtmlOptions.Engine = engineType;
...
...
If you have a suggestion or different solution, please leave a comment.
In regedit use the following steps
1)HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node
2)Create a key DWORD 32 Bit
3) Rename it "w3wp.exe"
4) Set Value Date = 1
I'm trying to buy something at Paypal-Sandbox with Selenium RC (Java), but it doesn't work.
I tried it with Selenium IDE (Firefox AddOn) and it did work. I changed the viewing and copied the JUnit 4 Code and it still doesn't work.
The problem is the part with the radio-button "payment_type_paypal". Somehow it doesnt work in RC (the radio-button is not checked). Do someone have similiar experiences and/or resolved the issue?
After loging in to developer.paypal.com and entering the homepage...
//linking homepage
selenium.click("legalTerms");
selenium.click("pay");
selenium.waitForPageToLoad("30000");
//leaving homepage and switching to paypal
selenium.click("payment_type_paypal"); // <===== point of error
selenium.type("login_email",username);
selenium.type("login_password",pw);
Thx :)
its me againg, Krzys. I know now the Problem. Its an issue with focussing the correct frame. I couldn't get it work with Selenium RC.
You can easily fix the issue in Selenium WebDriver with the command, before my "point of error":
driver.switchTo().defaultContent();
its me again. If you encounter problems with the Sandbox System of Paypal, you can overcome the "submit"-button issues using xpath.
driver.findElement(By.xpath("//div[#id='nav-menu']/form/ul/li/ul/li[6]/input")
Greetz
Krzys
Watin Runtime Version: v2.0.50727
Browser: IE 9
I have found a specific issue:
BaseIEController.IE.Element(fieldname).Exists throws an Exception as under:
"It's not possible to find the element because no element finder is available."
The fieldname here is a Regex for a link, a simple Regex where the Link's Id is passed.
This works with IE 8.
I cannot use the Final Release of Watin 2.0 since the LogonHandler is not complete (not fully functional as mentioned in the Release Document. I have tried testing it as well).
Any idea on how I can get this Element thingy to work??
Thanks,
K
Today I have upgraded to IE9 on my windows 2008 system and run all the 745 WatiN 2.x unittests and found no issues (accept for one dialog handling the javascript::return dialog fired by onbeforeunload event).
Let me know if you have more specific info/ code example will help too to reproduce the issue you reported.
Jeroen
Lead dev WatiN
Thank you for the response. Firstly, Awesome job with Watin :)
I am trying to run the test using VS2008 and IE 9. The goal is to Click a Link but before that I am verifying if the Link is exists.
The Regex I use for this link is LnkSignIn = new Regex(".*linkSignIn$");
I then use BaseIEController.IE.Element(fieldname).Exists where the fieldname is an Attribute Constraint (in this case the Regex). This would return a true or false if the Link is found. If found, I then click the Link. Instead it returns the Error MyTestInitialize threw exception. WatiN.Core.Exceptions.WatiNException: WatiN.Core.Exceptions.WatiNException: It's not possible to find the element because no element finder is available.. at WatiN.Core.Element.WaitUntilExistsOrNot(Int32 timeout, Boolean waitUntilExists)
...
This works just fine with IE 8. Further, I noticed that if I change Element to Link, it returns true. But since this is a generic method, I want to keep it as element. Hope this helps. Please let me know if you need more information. Thanks.