Summary: | defining line height affects height of text box | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | jasneet <jasneet> | ||||||||||||||||
Component: | Forms | Assignee: | gur.trio | ||||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||||
Severity: | Normal | CC: | buildbot, commit-queue, darin, esprehn+autocc, glenn, gur.trio, jasneet, macpherson, menard, rniwa, webkit | ||||||||||||||||
Priority: | P2 | Keywords: | HasReduction | ||||||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||||||||
Hardware: | PC | ||||||||||||||||||
OS: | Windows XP | ||||||||||||||||||
URL: | http://developers.facebook.com/tools.php?fbml | ||||||||||||||||||
Attachments: |
|
Description
jasneet
2008-02-29 16:36:15 PST
Created attachment 19463 [details]
screenshot
Created attachment 19464 [details]
reduction
Very odd issue. Check this test case: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3Cp%20style%3D'border%3A1px%20solid%20red%3B'%3Etest%20test%20%3Cinput%20type%3D'text'%20style%3D%22line-height%3A10em%3B%22%3Etest%3Cbr%3Etest%20test%20test%20test%20test%20test%20test%20%3C%2Fp%3E Notice strange very height of input box. Created attachment 209966 [details]
Patch
Giving line height to input elements increase the height of the element. To make it work similiar as Mozilla and IE line-height :normal should be applied for input elements. https://bugzilla.mozilla.org/show_bug.cgi?id=82265 Hi Darin. Could you please review this. Thanks Comment on attachment 209966 [details] Patch Attachment 209966 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/1624635 New failing tests: fast/forms/placeholder-position.html Created attachment 209983 [details]
Archive of layout-test-results from webkit-ews-10 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-10 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.4
Comment on attachment 209966 [details] Patch Attachment 209966 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/1581987 New failing tests: fast/workers/termination-with-port-messages.html fast/forms/placeholder-position.html Created attachment 209988 [details]
Archive of layout-test-results from webkit-ews-01 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-01 Port: mac-mountainlion Platform: Mac OS X 10.8.4
Created attachment 210346 [details]
Patch
Comment on attachment 210346 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=210346&action=review > Source/WebCore/css/html.css:425 > +input { > + line-height:normal !important; > +} Trying to prevent this with a user-agent stylesheet change will make line-height value of normal visible in getComputedStyle on the input element; because of that I think this is wrong. Unless the specification or standard practice in other browsers is to return "normal" as the computed style for the input element. Instead we can turn off the line-height inside the shadow DOM constructed by the input element somewhere in the RenderTextControl class. Can you please test what getComputedStyle does in these other browsers? (In reply to comment #11) > (From update of attachment 210346 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=210346&action=review > > > Source/WebCore/css/html.css:425 > > +input { > > + line-height:normal !important; > > +} > > Trying to prevent this with a user-agent stylesheet change will make line-height value of normal visible in getComputedStyle on the input element; because of that I think this is wrong. Unless the specification or standard practice in other browsers is to return "normal" as the computed style for the input element. Instead we can turn off the line-height inside the shadow DOM constructed by the input element somewhere in the RenderTextControl class. > > Can you please test what getComputedStyle does in these other browsers? The Test case input-line-height.html shows the following results. The test case compares getComputedStyle's line-height with style's line-height IE : FAIL for all inputs i.e getComputedStyle's line-height and style's line-height are same (both values show 50px) Mozilla : PASS for all inputs i.e getComputedStyle's line-height and style's line-height are different.(getComputedStyle's line height shows 16px and style's line height shows 50px) Mozilla as I can see is doing through .css Comment on attachment 210346 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=210346&action=review >>> Source/WebCore/css/html.css:425 >>> +} >> >> Trying to prevent this with a user-agent stylesheet change will make line-height value of normal visible in getComputedStyle on the input element; because of that I think this is wrong. Unless the specification or standard practice in other browsers is to return "normal" as the computed style for the input element. Instead we can turn off the line-height inside the shadow DOM constructed by the input element somewhere in the RenderTextControl class. >> >> Can you please test what getComputedStyle does in these other browsers? > > The Test case input-line-height.html shows the following results. The test case compares getComputedStyle's line-height with style's line-height > > IE : FAIL for all inputs i.e getComputedStyle's line-height and style's line-height are same (both values show 50px) > Mozilla : PASS for all inputs i.e getComputedStyle's line-height and style's line-height are different.(getComputedStyle's line height shows 16px and style's line height shows 50px) > > Mozilla as I can see is doing through .css OK, lets go with the CSS solution. There should be a space after the colon to match the rest of the html.css file. Created attachment 210429 [details]
Patch
(In reply to comment #14) > Created an attachment (id=210429) [details] > Patch Uploaded new patch as per the review comments. y(In reply to comment #13) > (From update of attachment 210346 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=210346&action=review > > >>> Source/WebCore/css/html.css:425 > >>> +} > >> > >> Trying to prevent this with a user-agent stylesheet change will make line-height value of normal visible in getComputedStyle on the input element; because of that I think this is wrong. Unless the specification or standard practice in other browsers is to return "normal" as the computed style for the input element. Instead we can turn off the line-height inside the shadow DOM constructed by the input element somewhere in the RenderTextControl class. > >> > >> Can you please test what getComputedStyle does in these other browsers? > > > > The Test case input-line-height.html shows the following results. The test case compares getComputedStyle's line-height with style's line-height > > > > IE : FAIL for all inputs i.e getComputedStyle's line-height and style's line-height are same (both values show 50px) > > Mozilla : PASS for all inputs i.e getComputedStyle's line-height and style's line-height are different.(getComputedStyle's line height shows 16px and style's line height shows 50px) > > > > Mozilla as I can see is doing through .css > > OK, lets go with the CSS solution. > > There should be a space after the colon to match the rest of the html.css file. Hi Darin. Anything else needs to be done for this issue? Comment on attachment 210429 [details] Patch Clearing flags on attachment: 210429 Committed r155324: <http://trac.webkit.org/changeset/155324> All reviewed patches have been landed. Closing bug. *** Bug 17751 has been marked as a duplicate of this bug. *** |