TWEagle / jquery-watermark

Automatically exported from code.google.com/p/jquery-watermark
1 stars 1 forks source link

Cannot enter Text identical to the placeholder if useNative: false #113

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Have a multiline textfield that only works if the placeholder can be 
multiline (hence the need for the plugin in the first place)
2. Enter the exact same text as the placeholder (multiple lines and all)
3. Be surprised that the text dissapears and is rendered as the placeholder as 
soon as you blur the textarea

What is the expected output? What do you see instead?
* That the text I entered myself will always be respected as user input and is 
not removed on blur.

What version of the product are you using? On what operating system?
3.1.4, Safari

Please provide any additional information below.

We used this html:
--- snip ---
<form id="demo4" action="" method="GET" class="cmxform">
    <h3>Demonstration 4</h3>
    <fieldset>
        <legend>Multi-line watermark in a TEXTAREA tag</legend>
        <ol>
            <li><label for="d4-name">Name <em>*</em></label> <input id="d4-name" /></li>
            <li><label for="d4-address">Address <em>*</em></label> <textarea id="d4-address" name="d4-address" rows="4" cols="60"></textarea></li>
            <li><label for="d4-country">Country</label> <input id="d4-country" /></li>
            <li><label></label> <input id="d4-submit" type="submit" value="Submit" /></li>
            <li><label></label> &bull; This is a normal <strong>type=&quot;submit&quot;</strong> button. We attempt to watermark the button, but it should have no effect.</li>
            <li><label></label> &bull; Check the QueryString after clicking to verify that a watermark value is never submitted.</li>
        </ol>
    </fieldset>
</form>
--- snap ---

And this js to trigger the bug
--- snip ---

    $(function () {
        $("#d4-address").watermark("Full street address\nCity, state and zip\nUse as many lines as necessary.", {useNative: false});
        $("#d4-submit").watermark("No watermark should be set.");
    });
--- snap ---

Original issue reported on code.google.com by mhaec...@gmail.com on 1 Jul 2013 at 2:05

GoogleCodeExporter commented 9 years ago
As a note, we found this bug when we added a watermark into a text field that 
specifies an example of what the input could be.

Original comment by mhaec...@gmail.com on 1 Jul 2013 at 2:06

GoogleCodeExporter commented 9 years ago
Read the Troubleshooting section on the project home page.  

Original comment by t...@speednet.biz on 1 Jul 2013 at 9:50

GoogleCodeExporter commented 9 years ago
https://code.google.com/p/jquery-watermark/#Can't_enter_the_same_text_as_the_wat
ermark

This describes a workaround for the issue. Is it possible to distinguish 
whether the watermark text has been set explicitly by the plugin when it 
encountered empty text versus when the user has entered the watermark text?

Original comment by robert.b...@goodpoint.de on 2 Jul 2013 at 7:44

GoogleCodeExporter commented 9 years ago
No, that's the way it works.

Original comment by t...@speednet.biz on 2 Jul 2013 at 10:26

GoogleCodeExporter commented 9 years ago
Out of curiosity, it does work if useNative is true. Wouldn't it be possible to 
set a data-attribute when the placeholder text is entered (by the plugin) and 
remove it when it is replaced by user input?

That way the plugin could distinguish  the two settings and show the correct 
stuff.

Original comment by mhaec...@gmail.com on 2 Jul 2013 at 10:48

GoogleCodeExporter commented 9 years ago
Out of curiosity, do you not want this to work in the watermark plugin?

Because it seems there are some options available to make this work, but 
there's no sense in trying if you do not want to support this?

Original comment by mhaec...@gmail.com on 5 Dec 2013 at 2:49

GoogleCodeExporter commented 9 years ago
No, I would not want to change the way it works, although I do appreciate the 
input.  The number of browsers requiring non-native watermarks is shrinking, 
and modern browsers can support styled watermarks (placeholders).  So the edge 
cases (which can be worked around as described in the troubleshooting section) 
are not worth complicating the plugin.

If you really think someone is going to type "Username" into an input element 
in which you have a watermark defined as "Username", then simply add some 
spaces to the end of the watermark -- as described in the troubleshooting 
section.

Original comment by t...@speednet.biz on 5 Dec 2013 at 3:17