Bug 10137 – REGRESSION: Width style attribute not applied the same to unstyled <input type="text"> in WebKit as for Safari

• Component: Layout and Rendering
• Status: RESOLVED INVALID

[Jason Prell (superrcat)]

Using 2006-07-28 r15664 of WebKit on Mac OS X v10.4.7 PPC, input elements with a type of password are not the correct width when the width is set with the style attribute.

The elements below will render with different widths using r15664:

<input name="txtUserName" type="text" id="txtUserName" tabindex="1" style="width:130px;" />
<input name="txtPassword" type="password" id="txtPassword" tabindex="2" style="width:130px;" />

This is a regression and did not occur with WebKit/418.8 Safari/419.3 (2.0.4).

An example can be viewed at the login page for the URL on this bug. Attached are also images from r15664 and WebKit/418.8.

[Jason Prell (superrcat)]

Created attachment 9729 [details]
input text and password type rendering with styled width on 418.8

[Jason Prell (superrcat)]

Created attachment 9730 [details]
input text and password type rendering with styled width on r15664

[Jason Prell (superrcat)]

The problem with password fields is tracked in <a href="show_bug.cgi?id=6990" title="ASSIGNED - Switch to use new text field implementation for &lt;input type=&quot;password&quot;&gt;">bug 6990</a>. Adding dependency.

[Gustaaf Groenendaal (MysteryQuest)]

Confirmed.

The bug does not seem to be caused by incorrect handling of the width element, but comes from somewhere else, probably a NativeTextfield issue.

[David Kilzer (:ddkilzer)]

Regressions are P1.  Adding NeedsRadar keyword.

The password field actually has the width specified, 130 px, when I measure it. It's the normal text field that has the wrong length, 136 px.

I tried with widths down to 0px, and the normal text field always has a real ("outer") width that is 6px more than the declared, while the password text field stays at the exact declared value. For example, a text field of width 0px is actually 6px wide, while a password text field with width 0px really is 0px wide, i.e. invisible.

For comparison, Firefox 1.5 adds 4px for each field ("outer" width), compared to declared width.

The normal text field and the password text field should at least be the same "outer" width, for same declared. Changing summary.

I measured with "Free Ruler".

Learning more about how width styles and such work for text inputs, it seems parts of my last comment are irrelevant, including, probably the new summary. :(

In any case, it is the text field visible width that has changed from Safari to latest WebKit, for the same applied style width. I think this is the real regression, so changing summary again.

[Jason Prell (superrcat)]

<rdar://problem/4672845>

[Jason Prell (superrcat)]

Created attachment 9952 [details]
Reduction for this bug

Attaching reduction for this bug.

[Adele Peterson]

This is caused by a change to match Firefox & IE that makes text fields and textareas use the correct box model when in strict mode.  Password fields haven't been transitioned to the new text field implementation yet, so that's why they're different.  If you remove the doctype, you'll see that in quirks mode, our new text fields will begin including the border & padding in the width, and in the test case both fields will have matching widths.  When the password fields are fully transitioned, you'll see that in strict mode, the specified width will *not* include border and padding for both kinds of text fields.