Closed Bug 1084906 Opened 8 years ago Closed 8 years ago

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

Categories

(Web Compatibility :: Desktop, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Swarnava, Assigned: karlcow)

References

()

Details

(Keywords: testcase, Whiteboard: [country-in] [css] [sitewait])

Step to reproduce:

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

try to fill the form.

input method is not working.
I get the same issue in IE11 but it works in safari.
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.
Component: Untriaged → Layout: Form Controls
Keywords: testcase
OS: Mac OS X → All
Product: Firefox → Core
Hardware: x86 → All
Summary: cannot fillup signup form on coupondunia.in → Can't enter text in input box with border-box layout and combined padding > height
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.
Component: Layout: Form Controls → Desktop
Product: Core → Tech Evangelism
Sorry, I meant to say we clip at the *content* edge for text inputs.
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
First attempt at a contact
http://twitter.com/MozWebCompat/status/526644151233044480
Assignee: nobody → kdubost
Status: NEW → ASSIGNED
Whiteboard: [country-in] [css] [sitewait]
See Also: → 1093626
> 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
Looks like the issue has been fixed!
See Also: → 1117532
I think we can call this FIXED as a Tech Evang bug.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Hello everyone. All the subsequent issues on other sites should be on Bug 1117532
(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.)
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.
Restrict Comments: true
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.