I have a HTML DIV on my page and I am trying to assign the innerHTML value of this DIV using HTML string returned in an AJAX callback. When this happens IE9 and IE10 report the below error if "Display a notification about every script error" is turned ON in settings.
SCRIPT1025: Label redefined
I inspected the HTML returned in AJAX callback however it doesn't contain elements (all elements not just labels) with duplicate id or name attributes.
FireFox and Chrome browsers do not have this issue.
Any thoughts/anyone faced this issue before?
Thanks in advance.
Related
I am scraping elements from a web page & I can see the element being visible (numeric value) on the web page in a grayed out box ,but when tried to inspect the element I cant find it between the tags. I assumed the URL might be any webservice endpoint & tried to GET from postman but it returned mere HTML code not a JSON response.
In general, we can get values between the tags by finding the element & getting innerText attribute in selenium that too failed as there is no text in between the tags.
I cannot post any URL or responses due to security compliance issues in my org. Please advise any other way I can work around.
Got my answer , tried running JS code "document.querySelector('input[name=assets_tot_mfr]').value;" and ran it through python execute_script. Thanks
I've searched on google but I couldn't get anywhere. I've added the Formspree contact form to a website and after initial set up it worked. After I activated and confirmed my email I sent one more email just to be sure it's up and running and when I click send I receive an error message. Error message
This is what the html code looks like
HTML
Not sure what I'm doing wrong. I'm relatively new to web development so any help would be greatly appreciated!
I think this problem occurred due to absence of name attribute in the input fields of the form. It is also given on the "Integration" section of the forms you created in the formspree.io.
It says Finally, ensure that each input has a name attribute.
Im wrestling with this right now. What browser/OS are you running? My form is currently working in Chrome on OS X, but Safari gives me that error.
Have you tried different browsers?
I found the answer on Formspree's website:
You are using an old Safari version, Safari mobile or some other
browser that is not recent Chrome, Firefox or Edge. In this case you
could have been a victim of an old HSTS policy we had on Formspree
that didn't allow sites to post content to non-https versions of
Formspree. In this case please change your form's action= attribute to
https://formspree.io/your-email.
I see an onprogress when I inspect a Form element, on Chrome and Firefox (both latest stable versions). Can I use it to monitor the progress of the form submission?
I want to submit/upload a file (that will be big most of the time) to a server that is not under my control, I can't just do a POST to it with XMLHttpRequest because it won't send any of the CORS required headers. So I'm going for the form/iframe way, creating a form element with all the fields, add a file input, append to the file input the file instance I got from another dialog, create an iframe and set the target of the form to the name of the iframe.
Is this onprogress attribute something I can use? I can't find any docs regarding the onprogress attribute of a form. Is that just an inherited attribute or does it actually work?
I have a page in XPages that I use to open and edit a document. There are two ways to open a document in edit-mode: first in read-mode then click a button to put it in edit-mode, or open it directly in edit-mode. Both work in all browsers, yet IE seems to handle both cases differently. We found this out when working with the SWING API.
Opening directly in edit-mode in IE (8/9/10) works, via read-mode to edit-mode doesn't. What we found is that the internal representation of a textarea field differs: when opened in edit-mode, there are more properties, but most importantly, the return+linefeeds are correctly set in both the value and the innerText property.
The button just contains a simple Change Mode action.
Has anyone heard of this anomaly? And does someone know what we did wrong?
PS I'll try to build a simple XPage that shows this behaviour more clearly tomorrow.
For IE switching from read to edit mode, you need a full page refresh
I am testing web application behavior with Cucumber (using Selenium and Watir under the hood). My web app has HTML5 pages and makes use of the new "required" attribute. If I have a data entry form with a required field, and I submit that form with the field blank, I would like to verify that the web app correctly responds with an error condition.
Unfortunately, when testing using an HTML5 web browser, the error message that pops up on a failed field validation does not appear to be accessible to Cucumber through the web driver. In any case, the form is not submitted and the page remains on the data entry form.
On the other hand, when testing headless or with a non-HTML5-compliant browser, the form may submit, allowing my web app to trap the error and send the user back to the form page with an error message.
In the second case, I can easily test for the existence of the error message since it's part of the HTML delivered in the page. My problem is that I can't see how to write a single test scenario that will validate the error condition for both headless and HTML5 browser situations.
It may be that this is impossible with the current state of Selenium and Watir web drivers. But if anyone has any idea how I can verify the HTML5 "required" error popup message, that would be a big help.
EDIT 2012-06-02:
Here is a sample page with a sampling of HTML5 browser warnings.
There is a required text and select, a text box showing internal hint text, and a text box with regex input validation. The page doesn't have any CSS or javascript to confuse the issue, it's just vanilla HTML5. See the w3schools page about HTML5 field attributes for a complete breakdown. The form submits to a simple CGI script that just echoes the form input, assuming the form succeeds. A submit failure will remain on the sample form page.
I haven't worked with the HTML5 required attribute before. But from the looks of it, that required attribute just alerts the browser that that form field must be filled out (i.e. the DOM doesn't change).
It seems to me that it would be reasonable to just assert that that required attribute is present in the HTML of the appropriate form fields. That test should pass for BOTH HTML5 browsers and non-HTML5 browsers.
Trying to assert anything more than that seems to me like you'd be testing the functionality of the browser.
Other than validating that the HTML created is correct to enable the browser validation, I'm not sure how much you can do that doesn't amount to testing the browser and not your code.
Using watir or watir-webdriver you could use .type to validate that the input has the proper type (e.g. email) set, which is one thing that controls the browser validation. The other is the presence of the required attribute which is a little tricker Potentially .attribute_value("required") might work, but normally that returns the value of an attribute, so not sure how that method would respond to a boolean attribute. Other alternatives might be to look at .attribute_list and
Seems also like a good reason here for Watir to add a .required? method to input elements that would allow you to easily check if that attribute has been set. So I asked for that feature https://github.com/watir/watir-webdriver/issues/189
You should have CSS selectors in place to target the particular field and look for an error identifier. If it is visible or not. A detailed step definition needs to be there.
One solution would be to not use Cucumber to test the error behaviour but instead test that you have configured the fields.
So in Cuke terms you might have something like
Given I am filling in my form
Then I should see that my name is required
and then write something that looks for the required option on the html tag for the name field.
Anymore than that is testing the browser not your application.