RESOLVED FIXED 103569
Support ruby-position: {before, after}
https://bugs.webkit.org/show_bug.cgi?id=103569
Summary Support ruby-position: {before, after}
mitz
Reported 2012-11-28 15:42:52 PST
Support ruby-position: {before, after}
Attachments
Add -webkit-ruby-position: {before,after} (48.10 KB, patch)
2012-11-28 15:57 PST, mitz
andersca: review+
webkit.review.bot: commit-queue-
results from chromium (4.55 KB, image/png)
2012-11-29 13:30 PST, Zhenyao Mo
no flags
mitz
Comment 1 2012-11-28 15:43:13 PST
mitz
Comment 2 2012-11-28 15:57:48 PST
Created attachment 176593 [details] Add -webkit-ruby-position: {before,after}
WebKit Review Bot
Comment 3 2012-11-28 17:14:00 PST
Comment on attachment 176593 [details] Add -webkit-ruby-position: {before,after} Attachment 176593 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/15016602 New failing tests: fast/ruby/position-after.html
mitz
Comment 4 2012-11-29 10:45:43 PST
(In reply to comment #3) > (From update of attachment 176593 [details]) > Attachment 176593 [details] did not pass chromium-ews (chromium-xvfb): > Output: http://queues.webkit.org/results/15016602 > > New failing tests: > fast/ruby/position-after.html Moved the expected results to platform/mac, since I couldn’t see what the failure looked like. Committed <http://trac.webkit.org/r136142>.
Zhenyao Mo
Comment 5 2012-11-29 11:33:41 PST
mitz: ping. fast/ruby/position-after.html is failing in chromium. Do you know why is that? This is blocking me from rolling webkit into chromium. Please get back to me soon. Otherwise I'll have no choice but revert this patch.
mitz
Comment 6 2012-11-29 12:52:07 PST
Can you attach the pixel result from chromium so that I can see what is failing? Unfortunately the EWS bot didn't provide it.
Zhenyao Mo
Comment 7 2012-11-29 13:21:27 PST
I see what's wrong. In the reviewed patch, the expectation files are under fast/ruby, which is for all platform, but in the landed patch, the expectation files are under platform/mac/fast/ruby
Zhenyao Mo
Comment 8 2012-11-29 13:22:18 PST
I'll rebaseline then. I only looked at the reviewed patch in the beginning, that's why I was very confused.
mitz
Comment 9 2012-11-29 13:28:14 PST
(In reply to comment #7) > I see what's wrong. In the reviewed patch, the expectation files are under fast/ruby, which is for all platform, but in the landed patch, the expectation files are under platform/mac/fast/ruby I explained why I did that in comment #4.
Zhenyao Mo
Comment 10 2012-11-29 13:30:57 PST
Created attachment 176804 [details] results from chromium
Zhenyao Mo
Comment 11 2012-11-29 13:31:43 PST
I just attached one rendered image from chromium, please have a look and let me know if it's OK to move the expectations into fast/ruby.
mitz
Comment 12 2012-11-29 13:42:21 PST
(In reply to comment #11) > I just attached one rendered image from chromium, please have a look and let me know if it's OK to move the expectations into fast/ruby. These results show a genuine failure in the positioning of emphasis marks in vertical text in Chromium. I doubt that the failure is new as a result of the patch. You should probably file a bug about that and skip the test on Chromium. You could also move the results to fast/ruby.
Jussi Kukkonen (jku)
Comment 13 2012-11-29 14:17:41 PST
(In reply to comment #12) > (In reply to comment #11) > > I just attached one rendered image from chromium, please have a look and let me know if it's OK to move the expectations into fast/ruby. > > These results show a genuine failure in the positioning of emphasis marks in vertical text in Chromium. I doubt that the failure is new as a result of the patch. You should probably file a bug about that and skip the test on Chromium. You could also move the results to fast/ruby. That would probably be best. Currently this test fails on all bots except mac. Thats said, I was just about to move the mac results to non-platform specific folder as the positioning on EFL is the same, when I realised the images have a strange color problem: In the efl results the 0000FF elements are really 0000FF but in the mac png results they seem to be 0433FF. Is this supposed to happen?
Kent Tamura
Comment 14 2012-11-29 17:28:43 PST
Please announce the feature to webkit-dev though I think no one objects it. http://www.webkit.org/coding/adding-features.html
mitz
Comment 15 2012-11-29 18:06:46 PST
(In reply to comment #14) > Please announce the feature to webkit-dev though I think no one objects it. > http://www.webkit.org/coding/adding-features.html Done. Thanks for the reminder!
WebKit Review Bot
Comment 16 2012-11-30 13:19:56 PST
Re-opened since this is blocked by bug 103768
Ryosuke Niwa
Comment 17 2012-12-11 14:17:03 PST
Note You need to log in before you can comment on or make changes to this bug.