RESOLVED FIXED 13282
REGRESSION (NativePopUp): Rightmost character cut off in pop-up menu
https://bugs.webkit.org/show_bug.cgi?id=13282
Summary REGRESSION (NativePopUp): Rightmost character cut off in pop-up menu
David Kilzer (:ddkilzer)
Reported 2007-04-04 14:58:23 PDT
Summary: Native pop-up menu has the right-most character cut off. Steps to reproduce: 1. Open Safari/WebKit. 2. Open test case. Expected results: The right-most character should not be cut off. Actual results: The right-most character is cut off. Regression: This is a regression from shipping Safari 2.0.4 (419.3) on Mac OS X 10.4.9 (8P135). Notes: Tested with a local debug build of WebKit r20699 with Safari 2.0.4 (419.3) on Mac OS X 10.4.9 (8P135).
Attachments
Test case (63 bytes, text/html)
2007-04-04 14:59 PDT, David Kilzer (:ddkilzer)
no flags
Test case v2 (52 bytes, text/html)
2007-04-04 18:50 PDT, David Kilzer (:ddkilzer)
no flags
Make RenderMenuList draw the text directly, disabling rounding if necessary (76.69 KB, patch)
2007-04-06 09:08 PDT, mitz
mitz: review-
Patch showing the fake baseline calculation (8.73 KB, patch)
2007-04-07 15:14 PDT, mitz
no flags
Measure and render option text with run rounding (97.84 KB, patch)
2007-08-29 02:30 PDT, mitz
hyatt: review+
David Kilzer (:ddkilzer)
Comment 1 2007-04-04 14:59:06 PDT
Created attachment 13952 [details] Test case
David Kilzer (:ddkilzer)
Comment 2 2007-04-04 18:50:41 PDT
Created attachment 13955 [details] Test case v2 It appears that the proper width is not being calculated for dashes! This test case should have seven dashes then the number eight: -------8
mitz
Comment 3 2007-04-05 00:38:48 PDT
There's an inconsistency between how option text is measured and how it's drawn: void RenderMenuList::updateOptionsWidth() { // FIXME: There is no longer any reason to use a text style with the font hacks disabled. // It is a leftover from when the text was not drawn with the engine -- now that we render // with the engine, we can just use the default style as the engine does. TextStyle textStyle(0, 0, 0, false, false, false, false); Using a plain TextStyle instead fixes the bug but has the side effect of not matching the popup menu's width, since AppKit obviously doesn't perform the rounding hack. So that just moves the inconsistency to a different place. A better solution would be to disable the rounding hack also when drawing the button text.
Dave Hyatt
Comment 4 2007-04-05 01:02:40 PDT
Should force it to be left-aligned all the time too. :)
mitz
Comment 5 2007-04-06 09:08:27 PDT
Created attachment 13980 [details] Make RenderMenuList draw the text directly, disabling rounding if necessary This patch removes most of the RenderButton-derived code from RenderMenuList, instead making it simply paint its own text. This gives it control over text rounding, allowing it to match the platform's popup implementation. I am not sure that a PopupMenu static will be sufficient for deciding what to do (it's hard to tell currently). Maybe that part should be put off until it's needed.
mitz
Comment 6 2007-04-06 09:22:01 PDT
Comment on attachment 13980 [details] Make RenderMenuList draw the text directly, disabling rounding if necessary I have the binaries to go with this patch but I'm having trouble uploading them. I'll figure it out if I get a r+.
Darin Adler
Comment 7 2007-04-06 09:34:15 PDT
Comment on attachment 13980 [details] Make RenderMenuList draw the text directly, disabling rounding if necessary This patch looks great. I'd like Adele and maybe Hyatt to review too. I don't think it's too helpful to have a setText function if it's private and is just an inline that sets m_text, so I probably would have removed it.
mitz
Comment 8 2007-04-07 10:01:55 PDT
Comment on attachment 13980 [details] Make RenderMenuList draw the text directly, disabling rounding if necessary I got the vertical positioning wrong in some cases (e.g. the Web Inspector's popup; the text there also looks heavier -- I'll investigate).
mitz
Comment 9 2007-04-07 10:40:50 PDT
(In reply to comment #8) > (From update of attachment 13980 [details] [edit]) > I got the vertical positioning wrong in some cases ...and the baseline > the text there also looks heavier That's because of text-shadow (text-stroke is also missing).
mitz
Comment 10 2007-04-07 15:11:28 PDT
I think I managed to get the baseline calculation right (down to the accumulated rounding errors in the current implementation), but then I found myself copying in big chunks of InlineTextBox code in attempt to support all text effects and decorations, which didn't seem like the right thing to do. Now I'm not sure about the whole approach.
mitz
Comment 11 2007-04-07 15:14:10 PDT
Created attachment 13988 [details] Patch showing the fake baseline calculation
mitz
Comment 12 2007-04-07 16:56:17 PDT
(In reply to comment #10) > Now I'm not sure about the whole approach. Even without rounding hacks, you're not going to match AppKit due to kerning and ligatures. Might be best to just patch updateOptionsWidth().
Darin Adler
Comment 13 2007-04-11 02:10:34 PDT
mitz
Comment 14 2007-08-29 02:30:11 PDT
Created attachment 16151 [details] Measure and render option text with run rounding I think this could be the right thing to do for now.
mitz
Comment 15 2007-08-29 02:32:18 PDT
Created attachment 16152
Dave Hyatt
Comment 16 2007-08-29 15:18:41 PDT
Comment on attachment 16151 [details] Measure and render option text with run rounding r=me
Mark Rowe (bdash)
Comment 17 2007-08-30 15:44:53 PDT
Landed in r25322.
Note You need to log in before you can comment on or make changes to this bug.