If a input text field includes a readonly attribute but no value attribute, the height of the input field is rendered at a few pixels. I originally saw this issue at http://www.alamo.com/. I created a reduced test case of this page STEPS TO REPRODUCE 1. With TOT WebKit, open the test case "input_readonly_test.html" 2.The first input field renders at the correct height (uses both readonly and value attributes) but second input fails to render at the correct height (readonly attribute) RESULTS Input field that includes readonly attribute but no value attribute should still rendered at the correct default height. However, input field's height is only a few pixels. REGRESSION Yes, only occurs with native text fields on TOT WebKit.
Created attachment 7590 [details] Input readonly test case
This issue was filed as <rdar://problem/4507668>
bidi.cpp:1722 is where we set the special line height for contenteditable RenderBlocks.
Adding code in bidi.cpp to check for a shadowParentNode will do the trick, but I'm not sure that's the right approach. It seems like the RenderTextField should have some default height. Maybe RenderTextField should have a layoutInlineChildren method?
I'm confused why readonly breaks at all. How did you implement readonly? Did you make it turn off editability?
I would not make readonly and disabled shut off editability.
*** Bug 8373 has been marked as a duplicate of this bug. ***
Because of the way disabled & readonly fields work on the mac, it makes sense to turn off editability. You can't place a caret in either of these cases. For readonly fields, you can make a selection, but we don't need the field to be editable to do that. Maciej suggested setting a height on the inner div. I've experimented with that, but I haven't gotten anything working well yet.
Just setting a height on the div in createDivStyle messes up the baseline.
I have built it, and I confirm that the issue seems to be solved. Thanks guys!!
Verified with latest TOT Webkit build (r13990).