WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
85484
[EFL] Tracking corner not being painted for TextArea
https://bugs.webkit.org/show_bug.cgi?id=85484
Summary
[EFL] Tracking corner not being painted for TextArea
Thiago Marcos P. Santos
Reported
2012-05-03 05:46:15 PDT
Created
attachment 139995
[details]
Current buggy rendering result Neither is possible to resize by dragging the corner of the widget.
Attachments
Current buggy rendering result
(15.17 KB, image/png)
2012-05-03 05:46 PDT
,
Thiago Marcos P. Santos
no flags
Details
Patch
(2.47 KB, patch)
2012-06-01 07:18 PDT
,
Jussi Kukkonen (jku)
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Dominik Röttsches (drott)
Comment 1
2012-05-09 05:20:02 PDT
failing: BUGWK85484 : fast/css/resize-corner-tracking-transformed.html = TEXT BUGWK85484 : fast/css/resize-corner-tracking.html = TEXT
Jussi Kukkonen (jku)
Comment 2
2012-05-31 01:30:49 PDT
Results from a quick look: This happens because corner handle size comes from scrollbar thickness and the efl scrollbar says it has a thickness 0. It looks like the reason for this is efls special 'overlay scrollbar' implementation that just paints on top of the scrollable... I bet this is related to other scrollbar bugs as well: e.g. text gets selected when you drag the scrollbar (should probably write a test case for that). I think there's a proper way to do overlay scrollbars (at least the concept exists in webcore), I'll take a look at that. Comments from efl scrollbar experts welcome as well.
Jussi Kukkonen (jku)
Comment 3
2012-06-01 06:10:58 PDT
Huh, it looks like it Just Works with a simple usesOverlayScrollbars() const { return true; } plus returning a proper width in scrollbarThickness(). I'll test a bit more and make a patch.
Jussi Kukkonen (jku)
Comment 4
2012-06-01 07:18:27 PDT
Created
attachment 145302
[details]
Patch
Jussi Kukkonen (jku)
Comment 5
2012-06-01 07:34:06 PDT
(In reply to
comment #4
)
> Created an attachment (id=145302) [details] > Patch
This seems to work, also fixes
bug 87950
. * Includes a magic number for thickness: if there's a way to query scrollbar thickness from ScrollbarThemeEfl, please let me know. * I'm not sure the current thickness value is pixel-perfect: someone with more .edc experience could probably tell me... * there's no graphic for the resize handle. Any comments/advice on those are appreciated.
Gyuyoung Kim
Comment 6
2012-08-22 20:18:24 PDT
Comment on
attachment 145302
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=145302&action=review
(In reply to
comment #5
)
> * I'm not sure the current thickness value is pixel-perfect: someone with more .edc experience could probably tell me...
EFL port hasn't supported pixel test. So, we started to support pixel test in
Bug 94188
. I think this patch also should support pixel-test as well as layout test. But, too many tests aren't supported by pixel test in EFL port now. So, it may be difficult to find which tests are influenced by this patch. If so, in my opinion, this problem can be handled by a new bug linked to
Bug 94188
. Any other opinions? BTW, are there any differences in layout test ?
> Source/WebCore/platform/efl/ScrollbarThemeEfl.cpp:52 > + return thickness;
If thickness variable is not used by other functions, it seems return 8; with comment is enough.
http://trac.webkit.org/browser/trunk/Source/WebCore/platform/efl/RenderThemeEfl.cpp#L817
KwangYong Choi
Comment 7
2012-08-23 17:25:47 PDT
fast/forms/textarea-scroll-height.html fast/forms/textarea-scrolled-type.html Scroll bar isn't being fully rendered.
Michael Catanzaro
Comment 8
2017-03-11 10:40:39 PST
Closing this bug because the EFL port has been removed from trunk. If you feel this bug applies to a different upstream WebKit port and was closed in error, please either update the title and reopen the bug, or leave a comment to request this.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug