RESOLVED FIXED 149831
[GTK] Progress bar is broken on recent GTK+ 
https://bugs.webkit.org/show_bug.cgi?id=149831
Summary [GTK] Progress bar is broken on recent GTK+
ChangSeok Oh
Reported 2015-10-05 21:38:22 PDT
Created attachment 262495 [details] Progress bar looks bad. 1. Run <!DOCTYPE html> <progress value="22" max="100"></progress> 2. And see it with other browsers
Attachments
Progress bar looks bad. (20.71 KB, image/png)
2015-10-05 21:38 PDT, ChangSeok Oh 		no flags
Details
Patch (12.41 KB, patch)
2015-10-05 22:40 PDT, ChangSeok Oh 		no flags
DetailsFormatted DiffDiff
Patch (22.01 KB, patch)
2015-10-06 20:35 PDT, ChangSeok Oh 		no flags
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
ChangSeok Oh
Comment 1 2015-10-05 22:40:34 PDT
Created attachment 262499 [details] Patch
Carlos Garcia Campos
Comment 2 2015-10-05 22:56:57 PDT
Comment on attachment 262499 [details] Patch Thanks for the patch! Do we really need to skip the test for other platforms? Isn't there any existing layout test using the progress element? In that case I think it's a good idea to have a test for all platforms, I don't see why this is specific to GTK+.
ChangSeok Oh
Comment 3 2015-10-05 23:06:40 PDT
(In reply to comment #2) > Comment on attachment 262499 [details] > Patch > > Thanks for the patch! Do we really need to skip the test for other > platforms? Isn't there any existing layout test using the progress element? I think fast/dom/HTMLProgressElement/progress-bar-value-pseudo-element.html is the most relevant. But it tests just css styling for progress bars, not test a native progress bar. > In that case I think it's a good idea to have a test for all platforms, I > don't see why this is specific to GTK+. Because they don't use GTK+ =). This bug happens on only gtk port. Well, I can add a result for mac(El capitan), but not EFL, other mac platforms. I have no build for them. Can I get results without building them? If so, I will add them as well. =)
Carlos Garcia Campos
Comment 4 2015-10-05 23:31:24 PDT
(In reply to comment #3) > (In reply to comment #2) > > Comment on attachment 262499 [details] > > Patch > > > > Thanks for the patch! Do we really need to skip the test for other > > platforms? Isn't there any existing layout test using the progress element? > I think fast/dom/HTMLProgressElement/progress-bar-value-pseudo-element.html > is the most relevant. But it tests just css styling for progress bars, not > test a native progress bar. Ah, I see. > > In that case I think it's a good idea to have a test for all platforms, I > > don't see why this is specific to GTK+. > Because they don't use GTK+ =). This bug happens on only gtk port. > Well, I can add a result for mac(El capitan), but not EFL, other mac > platforms. I have no build for them. Can I get results without building > them? If so, I will add them as well. =) Yes, but this is not testing a specific GTK+ behaviour, this is just rendering a progress to make sure we don't break it again, so it's perfectly valid test for any platform. I don't think you need to provide test results for all platforms, gardeners of other platforms will do it. In case we really want to add a gtk specific test, we should probably use a gtk subir that is skipped in the global TestExpectations file, and added as Pass in the gtk TestExpectations. See what we do for gtk specific accessibility and pasteboard tests. This problem is quite common with GTK+ nowadays, every new GTK+ version breaks rendering of any form element, so maybe, what we can do is adding a gtk specific pixel test with all the forms, not only progress. Because I'm afraid other form elements are not tested either, and layout only is not enough for us, we need pixels in this case.
ChangSeok Oh
Comment 5 2015-10-06 20:35:25 PDT
Created attachment 262573 [details] Patch
ChangSeok Oh
Comment 6 2015-10-06 23:47:28 PDT
(In reply to comment #4) > This problem is quite common with GTK+ nowadays, every new GTK+ version > breaks rendering of any form element, so maybe, what we can do is adding a > gtk specific pixel test with all the forms, not only progress. Because I'm > afraid other form elements are not tested either, and layout only is not > enough for us, we need pixels in this case. Make sense. I will add gtk specific tests not to break native gtk forms in a different ticket. Thanks for your comment and the r+. =)
WebKit Commit Bot
Comment 7 2015-10-07 00:32:46 PDT
Comment on attachment 262573 [details] Patch Clearing flags on attachment: 262573 Committed r190662: <http://trac.webkit.org/changeset/190662>
WebKit Commit Bot
Comment 8 2015-10-07 00:32:50 PDT
All reviewed patches have been landed. Closing bug.
Alexey Proskuryakov
Comment 9 2015-10-07 21:58:04 PDT
fast/dom/HTMLProgressElement/native-progress-bar.html fails on Windows. Could you please add an expectation?
ChangSeok Oh
Comment 10 2015-10-07 23:10:22 PDT
(In reply to comment #9) > fast/dom/HTMLProgressElement/native-progress-bar.html fails on Windows. > Could you please add an expectation? Sorry for your incovenience. "WontFix" will be enough? or Skip?
Note You need to log in before you can comment on or make changes to this bug.