type="date" not working on Safari/iPad

[brOOper]

There is an issue on iPad's Safari with <paper-input type="date" />. It is only touchable if there is an initial value set. If there is no value or the value gets deleted the field is no longer touchable. Same for <paper-input type="time" />.

Browser: Mozilla/5.0 (iPad; CPU OS 9_2_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13D15 Safari/601.1

<paper-input type="date" label="no value (does not work)" />
<paper-input type="date" label="initial value (does work)" value="2016-03-03" />

https://plnkr.co/f5gzvmotEkEJ6zM5atsN

[43081j]

As far as I can see, the docs seem to imply this isn't yet supported (see here, The supported types are text, number and password.).

Edit:

Ignore me, the docs are contradictive, they also state:

A paper-input can use the native type=search or type=file features. However, since we can't control the native styling of the input (search icon, file button, date placeholder, etc.), in these cases the label will be automatically floated.

Your plunkr is using an old version of paper-input so i was getting some non-floating-label bugs with it, try use polygit instead.

[notwaldorf]

Yup, that looks like a bug. Here's a repro JSBin: http://jsbin.com/runurip/edit?html,output

[RobinLinus]

+1

[aarondrabeck]

+1

[kaseyhinton]

+1

[BorntraegerMarc]

whats happening with this issue? It's still not fixed...

[shawncplus]

Just ran into this on polymer version 1.9.1 though for type="time" instead of date. A raw input is="iron-input" type="time" works just fine so paper-input is definitely the culprit. Can't check to see if this is fixed in later versions atm. @BorntraegerMarc what version of Polymer were you on?

[BorntraegerMarc]

@shawncplus I was on polymer 2.0.1

[shawncplus]

So I have found a workaround. Apply any styles to it that will give the input element a height. So a border or anything really.

  .my-input {
    --paper-input-container-input: {
      min-height: 1px;
    };
  }

If I had to take a wild guess at why this works I'd say it's because:

• paper-input-container sets the padding to 0 and removes the border, this sets the inputs initial height to 0
• webkit, seeing the element has no height, does not force the element to layout
• because the element doesn't layout focusing it ignored
• because it doesn't receive focus the OS controls aren't shown
• Setting an initial value works because the input has content so has a height

Therefor the solution of setting a min-height on the input itself always causes it to layout

@BorntraegerMarc ^

Note: I verified this theory by using a plain ol' fashion input type="time" and setting padding: 0; border: none; outline: none; -webkit-appearance: none; and programatically focusing the element. Without min-height nothing happens. Adding a min-height: 1px and programatically focusing the element shows the OS controls.

[d4l3k]

This doesn't seem to be fixed. I'm still seeing this issue under 2.0.3.

http://jsbin.com/runurip/edit?html,output

[d4l3k]

Just confirmed, it's still a bug in 2.0.3 despite that recent pull request.

This still fixes it:

--paper-input-container-input: {
      min-height: 1px;
    };

[shawncplus]

@d4l3k yeah that's because I'm a big dummy and my PR was bad and had the min-height applied to the wrong class. I'll send in a fixed PR :/

I tested the code and took the PR test screenshots by directly modifying my bower_components files but when I copied the changes over to the repo I just dropped the change in the wrong spot. Whoops.

[mcabram]

It doesn't work in my mac book pro as well. That html is normal input type="date". It displays as type="text". Is this bug still here till today?

[jhongmez]

El error aun persiste, no he encontrado como darle solución a esto