Bug 149831

Summary: [GTK] Progress bar is broken on recent GTK+
Product: WebKit Reporter: ChangSeok Oh <changseok>
Component: WebKitGTKAssignee: ChangSeok Oh <changseok>
Status: RESOLVED FIXED    
Severity: Normal CC: cgarcia, commit-queue, esprehn+autocc, glenn, gustavo, kondapallykalyan, mrobinson
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Progress bar looks bad.
none
Patch
none
Patch none

Description ChangSeok Oh 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
Comment 1 ChangSeok Oh 2015-10-05 22:40:34 PDT
Created attachment 262499 [details]
Patch
Comment 2 Carlos Garcia Campos 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+.
Comment 3 ChangSeok Oh 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. =)
Comment 4 Carlos Garcia Campos 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.
Comment 5 ChangSeok Oh 2015-10-06 20:35:25 PDT
Created attachment 262573 [details]
Patch
Comment 6 ChangSeok Oh 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+. =)
Comment 7 WebKit Commit Bot 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>
Comment 8 WebKit Commit Bot 2015-10-07 00:32:50 PDT
All reviewed patches have been landed.  Closing bug.
Comment 9 Alexey Proskuryakov 2015-10-07 21:58:04 PDT
fast/dom/HTMLProgressElement/native-progress-bar.html fails on Windows. Could you please add an expectation?
Comment 10 ChangSeok Oh 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?