1084906 - Can't enter text in input box with border-box layout and combined padding > height

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Swarnava Sengupta (:Swarnava)]

Step to reproduce:

Go to http://www.coupondunia.in/profile/signup

try to fill the form.

input method is not working.

Comment 1

[Matthias Versen [:Matti]]

I get the same issue in IE11 but it works in safari.

Comment 2

[:Gijs (he/him)]

The input box has padding in excess of its height and therefore the text entry bits disappear. Here's a minimal testcase:

http://jsbin.com/tecusegewa/edit?html,css,output

I'm not sure what Chrome is doing here; looking at its devtools, it pretends the inner height is 0 just like for us - but it still shows the text and lets you edit it.

I'm also not sure what, if anything, the spec says about this - clearly the web developer is doing something that's basically silly, but also, Chrome's solutions is clearly more user-friendly than the one IE11 and we pick.

Comment 3

[Mats Palmgren (inactive)]

I think our layout is correct in this case, the content height is zero and we clip
at the padding edge for text inputs.

The error is the 'height: 34px'.  That's never a good idea because the user might
have specified a larger font size.  The fix is to remove that declaration.

Comment 4

[Mats Palmgren (inactive)]

Sorry, I meant to say we clip at the *content* edge for text inputs.

Comment 5

[Karl Dubost💡 :karlcow]

First of all, there are messages in the console that the form is insecure.

Password fields present on an insecure (http://) page. This is a security risk that allows user login credentials to be stolen.[Learn More]
Password fields present in a form with an insecure (http://) form action. This is a security risk that allows user login credentials to be stolen.[Learn More] 


This is indeed working on Safari.

signin-container .widder-input-password, .signin-container .widder-input {
    padding: 20px 9px;

As soon as we change the value to be <= 15px we start seeing some text in the form, but it requires to put the value to 8px or 9px to have something readable.


signin-container .widder-input-password, .signin-container .widder-input {
    padding: 8px 9px;

They have a twitter account but sends again and again the same messages. https://twitter.com/coupondunia/ They thank sometimes some people it seems. 


They do have in house Front-end devs
https://www.linkedin.com/jobs2/view/11805496

Their CEO seems active on twitter. Let's see.
https://twitter.com/sparwani

Comment 6

[Karl Dubost💡 :karlcow]

First attempt at a contact
http://twitter.com/MozWebCompat/status/526644151233044480

Comment 7

[Karl Dubost💡 :karlcow]

> I'm not sure what Chrome is doing here; looking at its devtools,
> it pretends the inner height is 0 just like for us - but it still
> shows the text and lets you edit it.

Yes it's quite strange.
I sent an email to the CSS Working Group just in case.

box-sizing and text in value attribute of input element Karl Dubost (Wednesday, 5 November) 
http://lists.w3.org/Archives/Public/www-style/2014Nov/thread.html#msg37

Comment 8

[Swarnava Sengupta (:Swarnava)]

Looks like the issue has been fixed!

Comment 9

[Swarnava Sengupta (:Swarnava)]

I think we can call this FIXED as a Tech Evang bug.

Comment 15

[Karl Dubost💡 :karlcow]

Hello everyone. All the subsequent issues on other sites should be on Bug 1117532

Comment 16

[Daniel Holbert [:dholbert]]

(I'm suspicious that comments 11-14 might be attempts at SEO spam instead of actual reports from users.  That happens in Bugzilla sometimes. If they are in fact reports from actual users, sorry for my mistaken assumption, and please include more details (e.g. instructions on what to do after loading your linked URL, to find the input box that reproduces the issue), and please note them on Bug 1117532 or on a new bug.)

Comment 23

[Daniel Holbert [:dholbert]]

I'm clearing the "URL" field from this bug, because I have a hunch that might be what's making it such a spam-trap.  (at least for the earlier coupon-related spam)

Comment 24

[Daniel Holbert [:dholbert]]

Actually, let's just get a bugzilla admin to restrict comments on this bug. In the unlikely event that there ends up being any legitimate followup comments here (e.g. concerns about the patch, regressions, etc), we can just file a new bug and mark it as blocking this one, and have that discussion there.