Bug 149831

Summary:

[GTK] Progress bar is broken on recent GTK+

Product:

WebKit

Reporter:

ChangSeok Oh <changseok>

Component:

WebKitGTK

Assignee:

ChangSeok Oh <changseok>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

cgarcia, commit-queue, esprehn+autocc, glenn, gustavo, kondapallykalyan, mrobinson

Priority:

Version:

WebKit Nightly Build

Hardware:

Unspecified

OS:

Unspecified

Attachments:

Description	Flags
Progress bar looks bad.	none
Patch	none
Patch	none

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	Details Formatted Diff Diff
Patch (22.01 KB, patch) 2015-10-06 20:35 PDT, ChangSeok Oh	no flags	Details Formatted Diff Diff
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.