26804 2009-06-29 10:25:34 -0700 Line Feed in input value attribute moves text out of button 2023-03-29 10:13:11 -0700 1 1 1 Unclassified WebKit Forms 528+ (Nightly build) All All RESOLVED DUPLICATE 238803 https://bugs.webkit.org/show_bug.cgi?id=173872 http://pt.wikipedia.org/w/index.php? title=Unaí&action=history HasReduction P2 Normal --- 1 jasneet webkit-unassigned ahmad.saleem792 akeerthi ap bfulgham cdumez jasneet rniwa simon.fraser vitor.roriz wenson_hsieh zalan oldest_to_newest 128830 0 jasneet 2009-06-29 10:25:34 -0700 I Steps: Go to http://pt.wikipedia.org/w/index.php? title=Unaí&action=history II Issue: Should appear this text: (Compare as versões selecionadas) on the bottom. III Conclusion : Issue is due to input.historysubmit { height: 1.7em !important; } IV Other Browsers: IE7: not ok FF3: ok V Nightly tested: 45330 Bug in Chromium : http://code.google.com/p/chromium/issues/detail?id=5680 128831 1 32011 jasneet 2009-06-29 10:25:59 -0700 Created attachment 32011 reduced testcase 1894653 2 ahmad.saleem792 2022-08-29 15:05:09 -0700 All browsers (STP 152, Chrome Canary 107 and Firefox Nightly 106) behave same and don't show any text in input field or any where not the webpage. In case of Chrome, I do get "Google Translate" but I don't know where it is detecting text. But visually all browsers are same. Although by following Chrome bug link, I noticed that they fixed it in following commit: https://chromium.googlesource.com/chromium/src.git/+/8dc8d77d8fa1645f44c306062070e5d40af2ba2c and using the test case form the commit: Link - https://jsfiddle.net/bfydqomw/show I am able to reproduce this bug: >>> STP 152 show "abc" in the button While both other browsers (Chrome Canary 107 and Firefox Nightly 106) show - abc in first line and defghi in second line within button. I am going to change this as "New". Thanks! 1896486 3 vitor.roriz 2022-09-06 06:12:54 -0700 >> Although by following Chrome bug link, I noticed that they fixed it in following commit: >> https://chromium.googlesource.com/chromium/src.git/+/8dc8d77d8fa1645f44c306062070e5d40af2ba2c Blink actually reverted this here https://chromium.googlesource.com/chromium/src.git/+/0c8d03bcf68d9c0e31d84369df15dec742682c73 It seems that back in the time IE solution was to strip out new-line characters from the input's value. Now, Firefox and Chrome render the value respecting the new line. Although we are passing the WPT tests for it (https://wpt.fyi/results/html/rendering/widgets/button-layout?label=master&label=experimental&aligned&view=subtest&q=input-type-button-new) it seems that the second line is overflowing and being clipped out. 1896746 4 vitor.roriz 2022-09-07 04:42:17 -0700 BaseButtonInputType::createRenderer instantiates a RenderButton. RenderButton is a RenderFlexibleBox that holds a RenderTextFRagment (which is a RenderText) to represent the test set as 'value' in the input. For a case where we have a 'value' with 2 lines, RenderFlexibleBox::layoutAndPlaceChildren is calculating the correct height for the multiple lines. Actually, the children (lines) are painted correctly. However, the height of the input (RenderFlexibleBox) itself is not updated accordingly. 1896768 5 vitor.roriz 2022-09-07 05:39:50 -0700 More specifically: RenderFlexibleBox::layoutFlexItems calls layoutAndPlaceChildren which updates RenderFlexibleBox height with: > setLogicalHeight(std::max(logicalHeight(), crossAxisOffset + flowAwareBorderAfter() + flowAwarePaddingAfter() + However, in the end layoutFlexItems updates logicalHeight for RenderFlexibleBox again with updateLogicalHeight(RenderFlexibleBox.cpp:1216). updateLogicalHeight calls RenderBox::computeLogicalHeight which sets logical height to a cached value, which does not account for the multiple lines. The following comment is relevant: > RenderBox.cpp:3221: > // The parent box is flexing us, so it has increased or decreased our height. We have to > // grab our cached flexible height. This happens exactly at RenderBox.cpp:3259 where we calculate hightResult = constrainLogicalHeightByMinMax(heightResult, intrinsicHeight). Being intrinsicHeight the height taking in consideration the children and highResult the cached height. 1925174 6 ahmad.saleem792 2023-01-12 15:39:40 -0800 It is still reproducible using test case from Comment 02 so it is not an overflow issue, which was fixed by Bug 173872. 1932615 7 ahmad.saleem792 2023-02-10 04:20:22 -0800 (In reply to Ahmad Saleem from comment #2) > All browsers (STP 152, Chrome Canary 107 and Firefox Nightly 106) behave > same and don't show any text in input field or any where not the webpage. In > case of Chrome, I do get "Google Translate" but I don't know where it is > detecting text. But visually all browsers are same. > > > Although by following Chrome bug link, I noticed that they fixed it in > following commit: > > https://chromium.googlesource.com/chromium/src.git/+/ > 8dc8d77d8fa1645f44c306062070e5d40af2ba2c > > and using the test case form the commit: > > Link - https://jsfiddle.net/bfydqomw/show > > I am able to reproduce this bug: > > >>> STP 152 show "abc" in the button > > While both other browsers (Chrome Canary 107 and Firefox Nightly 106) show - > abc in first line and defghi in second line within button. > > I am going to change this as "New". Thanks! This seems to work on Safari Technology Preview 163. It could be this commit - https://github.com/WebKit/WebKit/commit/1a0105921defca0770820813cdec1e805036c441 --> Although, using the attached 'reduced' test, we get artefacts, where the text is showing up small bits from bottom while it is not the case in Chrome Canary 112. Should we raise new bug and close this one? 1945035 8 ahmad.saleem792 2023-03-29 10:13:11 -0700 *** This bug has been marked as a duplicate of bug 238803 *** 32011 2009-06-29 10:25:59 -0700 2009-06-29 10:25:59 -0700 reduced testcase testcase.html text/html 687 jasneet PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPg0KPGh0bWwgZGlyPSJsdHIiIHhtbDpsYW5nPSJwdCIgeG1sbnM9Imh0dHA6Ly93d3cu dzMub3JnLzE5OTkveGh0bWwiIGxhbmc9InB0Ij4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0i Q29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPg0KPHRpdGxl PnRlc3Q8L3RpdGxlPg0KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4NCmJvZHkgew0KCWZvbnQ6IHgt c21hbGwgc2Fucy1zZXJpZjsNCn0NCg0KaW5wdXQuaGlzdG9yeXN1Ym1pdCB7DQoJDQoJZm9udC1z aXplOiA5NCU7DQoJaGVpZ2h0OiAxLjdlbSAhaW1wb3J0YW50Ow0KCQ0KfQ0KPC9zdHlsZT4NCg0K PC9oZWFkPg0KPGJvZHk+DQo8aW5wdXQgdmFsdWU9Ig0KQ29tcGFyYXIgYXMgdmVyc8O1ZXMgc2Vs ZWNpb25hZGFzIiBjbGFzcz0iaGlzdG9yeXN1Ym1pdCIgYWNjZXNza2V5PSJ2IiB0aXRsZT0iVmVy IGFzIGRpZmVyZW7Dp2FzIGVudHJlIGFzIGR1YXMgdmVyc8O1ZXMgc2VsZWNpb25hZGFzIGRlc3Rh IHDDoWdpbmEuIFthbHQtc2hpZnQtdl0iIHR5cGU9InN1Ym1pdCI+IA0KPC9ib2R5Pg0KPC9odG1s Pg0K