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
Created attachment 32011 [details] reduced testcase
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!
>> 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.
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.
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.
It is still reproducible using test case from Comment 02 so it is not an overflow issue, which was fixed by Bug 173872.
(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?
*** This bug has been marked as a duplicate of bug 238803 ***