I've noticed that browsers don't recognize my password field as a potential auto-complete target. I'm assuming this has something to do with the fact that the password field isn't in the original HTML - it's created by my GWT script after the page has loaded.
Is there a way to tell a browser, "hey, here's this form, treat it like usual?" How can I let browsers hook into my app for autofill?
There are some workarounds to get the browser to auto-complete your login like the one described here.
After struggling some time with it I strongly suggest you simply wrap an existing form of your host page (do not generate the inputs with GWT), do a form.submit() on it and have a servlet listen to the request.
I believe that password fields ( tags with type="password") are not auto-filled for fairly obvious security reasons. It doesn't matter that the field is added after page load by your GWT script.
Try mimicking the field in regular HTML and compare that to how your GWT app creates the DOM structure. Perhaps your GWT app is putting the page together differently?
Related
I'm trying to embed a value into the textbox at the USCIS government website to check my application status number. Suppose it's LIN1234. After inspecting the element of the webpage I see that the HTML wrapper for the textbox is:
<input id="receipt_number" name="appReceiptNum" class="form-control textbox initial-focus" maxlength="13" type="text">
I tried opening up this URL with a suffix added on, but to no avail:
https://egov.uscis.gov/casestatus/landing.do?receipt_num=LIN1234
Is there a way to to this?
Before that, you must understand what means adding ?receipt_num=LIN1234 to the url.
When sending a request (By default and in this context) from your browser, it'll be a GET request (see here) where you send as a get argument your receipt number, setting its key to receipt_num.
What is done to this data on the server side, however, is up to itself.
Just understand that unless the server is made to auto-fill the field with that value in case it receives it, it won't do anything except sending some more data.
I think you want to load this page in your browser with auto-filled field.
In that case you should look into extensions for your browser that would do that automatically.
You probably won't be able to embed a value into the textbox... Just because you are sending values by GET (which is what the landing.do?receipt_num=LIN1234 syntax is doing) doesn't mean that they have something set up to process it, so the GET variable will probably not do anything.
You might be able to see how their URLs work ordinarily, what the page URL that you are aiming to land on looks like, and either decode something from that or set a bookmark there. That said, if they are submitting that data via POST (which they probably are, for security reasons), that probably won't work.
I would suggest looking at reputable form-filling plugins for your web browser, if that's an option. That might allow you to work around that.
I am volunteering on a website-based project that is trying to make all pages fully operable JavaScript free before adding any JavaScript for enhancements, and I was asked to investigate whether or not a particular scenario could be handled purely through HTML/CSS.
What we have is a form that is populated to help us filter a list of tickets that are displayed on the screen after a page update through a GET action, which itself works fine, but the concern with the current implementation is that the URL cannot be made into a permanent link. The request, however, to keep the permanent link as minimal as possible, is to only send GET parameters for fields that are populated with something (so, suppressing GET parameters for fields that are blank) instead of having a different GET parameter for each form field on the page.
I have thought of several ways that could be done, most including JavaScript (example: create fields with ids but no names and a hidden field w/ name that uses JS to grab the data from the fields), but also one that would be a POST action with a redirect back to the GET with a human readable string that could be permanently used. The lead dev, however would prefer not to go through the POST/redirect method if at all possible.
That being said, I'm trying to make sure I cover all my bases and ask experts their thoughts on this before I strongly push for the POST/redirect solution: Is there a way using only HTML & CSS to directly suppress GET parameters of a form for fields that are blank without using a POST/redirect?
No, suppressing fields from being submitted in an HTML form with method of "GET" is not possible without using JavaScript, or instead submitting the form with a POST method and using a server side function to minimize the form.
What fields are submitted are defined by the HTML specification and HTML and CSS alone cannot modify this behavior and still have the browser be compliant with the standards.
No, you cannot programmatically suppress any default browser behavior without using some kind of client scripting language, like JavaScript.
As a side note, you say "JavaScript for enhancements", but JavaScript is not used for enhancements these days. And no one in the real world would except a decent front-end without the use of JavaScript. I would suggest you simply use JavaScript.
I do not think you can avoid Javascript here to pre process before submission to eliminate unchanged /empty form fields.
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.
Let's say someone is writing a reply to an online forum on their iPhone when they lose connection.
Is it possible to use HTML5 local storage to save their submission and post it when they get connection back?
If so, how do I tell if the phone has a connection or not?
Yes you can by implementing your custom logic into the app.
To see if a connection is available you could either use navigator.onLine flag (but it seems that is not completely reliable):
Does Safari and/or WebKit implement the equivalent of window.navigator.online?
http://html5demos.com/offline
or try to load content from the internet and see if it's possible or not:
Checking online status from an iPhone web app
Could you not use JavaScript to set a variable and make it a string with the content of whatever the user puts in the box? You could use getElementById or similar to get the content from the form.
Then, store it in a "cookie". If you don't know how to do this, here is a quick run down on javascript cookies from w3: http://www.w3schools.com/js/js_cookies.asp
Then on page load you could have it load the cookie and make the value of the form equal to the variable you declared earlier.
The best approach (in the light of navigator.onLine behaving inconsistently in different browsers) would be to save whatever the user is typing to localStorage every few seconds or every few keystrokes.
If the page is reloaded again, then you can make sure to first see if there is anything stored in the localStorage key, and if so, then load that into the text box and the user can continue from where he left off.
You can also take a look at the 'going offline with web storage' section of this article http://dev.opera.com/articles/view/taking-your-web-apps-offline-web-storage-appcache-websql/
I read some AJAX-Form tutorial like this. The tag form is used in HTML code. However, I believed that it is not necessary. Since we send HTTP request through XmlHttpRequest, the sent data can be anything, not necessary input in form.
So, is there any reason to have form tag in HTML for AJAX application?
Apart from progressive enhancement as already discussed (don't make your site require JavaScript until it really has to), a <form> with onsubmit would be necessary to reliably catch an Enter keypress submission.
(Sure, you can try trapping keypresses on separate form fields, but it's fiddly, fragile and will never 100% reproduce the browser's native behaviour over what constitutes a form submission.)
Sometimes, web apps using ajax to transform their data either use forms as a fallback when the user has no JavaScript enabled (a sometimes expensive but very good thing to do).
Otherwise, if an application builds and sends an AJAX request, there is no compelling reason to use a form except in rare special cases when you actually need a form element. Off the top of my head:
when using jQuery's form serialize function
when monitoring all fields in a form for changes
when there is need to make use of the reset form button (that to my knowledge is available in a proper <form> only).
I see at least two possible reasons :
Graceful degradation (see also Unobtrusive JavaScript) : if a user doesn't have Javascript enabled in his browser, your website should still work, with plain-old HTML.
Behavior of the browser : users know what forms look like and how they behave (auto-completion, error-correction, ...) ; it's best not going too far away from that
And I would add that, if you want the user to input some data, that's why <form> and <input> tags exist ;-)
Using the right tags also helps users -- as an example, think about blind users who are navigating with some specific software : those software will probably have a specific behavior for forms an input fields.
It really depends what you're doing. If you're wanting to take form content submitted by the user and use AJAX to send that somewhere then you're going to want to use the form tag so your user can enter their data somewhere.
There will be other times when you're not sending data from a form and in that case, you wont have a form to be concerned about :)