Closed
Bug 1072704
Opened 10 years ago
Closed 10 years ago
Textarea resize handle increase size and looks blurry when border property is changed
Categories
(Core :: Widget: Win32, defect)
Tracking
()
RESOLVED
FIXED
mozilla36
People
(Reporter: yanakey, Assigned: u518207, Mentored)
Details
(Whiteboard: [good first bug][lang=c++])
Attachments
(3 files)
User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2150.5 Safari/537.36 Steps to reproduce: Modify any border property: border-width, border-color etc. Actual results: Resize handle increase size and looks blurry. Expected results: It should look like handle on select element (second on attached picture).
Component: Untriaged → Layout: Form Controls
Product: Firefox → Core
Version: unspecified → Trunk
I've found that applying -moz-appearance: none; solves the problem.
Comment 4•10 years ago
|
||
Seems to be a Window thing in particular? The testcase looks fine on Mac...
Comment 5•10 years ago
|
||
Jim, do you know might be the right person to look into this native theming bit?
Comment 6•10 years ago
|
||
(In reply to yanakey from comment #2) > Created attachment 8495040 [details] > Testcase In this test case, which side is rendered correctly and which side is wrong?
(In reply to Jim Mathies [:jimm] from comment #6) > (In reply to yanakey from comment #2) > > Created attachment 8495040 [details] > > Testcase > > In this test case, which side is rendered correctly and which side is wrong? Right side is wrong, of course (:
Comment 8•10 years ago
|
||
(In reply to yanakey from comment #7) > (In reply to Jim Mathies [:jimm] from comment #6) > > (In reply to yanakey from comment #2) > > > Created attachment 8495040 [details] > > > Testcase > > > > In this test case, which side is rendered correctly and which side is wrong? > > Right side is wrong, of course (: I actually kinda like the right side (larger icon) better. :) Anyway, this is a polish bug and would make a good first bug I think. The problem is probably in our theme code on windows. bz, do you know if this little grabber has an NS_THEME theme constant associated with it? I'm guessing NS_THEME_RESIZER but that might be something else.
Comment 9•10 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #8) > (In reply to yanakey from comment #7) > > (In reply to Jim Mathies [:jimm] from comment #6) > > > (In reply to yanakey from comment #2) > > > > Created attachment 8495040 [details] > > > > Testcase > > > > > > In this test case, which side is rendered correctly and which side is wrong? > > > > Right side is wrong, of course (: > > I actually kinda like the right side (larger icon) better. :) Anyway, this > is a polish bug and would make a good first bug I think. The problem is > probably in our theme code on windows. > > bz, do you know if this little grabber has an NS_THEME theme constant > associated with it? I'm guessing NS_THEME_RESIZER but that might be > something else. Yes. http://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSProps.cpp#640 (the -moz-appearance setting for this is "resizer", as per DOM Inspector - see also comment #3)
Updated•10 years ago
|
Mentor: jmathies
Status: UNCONFIRMED → NEW
Component: Layout: Form Controls → Widget: Win32
Ever confirmed: true
Whiteboard: [good first bug][lang=c++]
Assignee | ||
Comment 10•10 years ago
|
||
After commenting lines 1829 and 1830 in nsNativeThemeWin.cpp: >DrawThemeBGRTLAware(theme, hdc, part, state, > &widgetRect, &clipRect, IsFrameRTL(aFrame)); Only the smaller grabber disappeared, but not a larger one. Ok, maybe the larger one uses Classic method; but not even that (commenting only line 3624 > ::DrawFrameControl(hdc, &widgetRect, part, state); did not affect the rendering: both grabbers rendered). Not only the grabbers doesn't use the same drawing method, the drawing method of the larger grabber wasn't found, unfortunately.
Assignee | ||
Comment 11•10 years ago
|
||
After some deeper investigation the rendering is as needed. If the widget type is resizer, we return true, because otherwise false is returned (in the next if statement) and theme rendering is turned off as it used to be before. The problem was that IsWidgetStyled method checked, for the resizer, whether parent frame is scrollable and the background or border was modified. If yes (like in our case), the method returned true and the resizer was reported as not supported by the theme.
Attachment #8502566 -
Flags: review?(jmathies)
Comment 12•10 years ago
|
||
Comment on attachment 8502566 [details] [diff] [review] 1072704.patch lgtm, thanks!
Attachment #8502566 -
Flags: review?(jmathies) → review+
Assignee | ||
Comment 13•10 years ago
|
||
Good!
Comment 14•10 years ago
|
||
remote: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=e30cc3e1e62a remote: https://tbpl.mozilla.org/?tree=Try&rev=e30cc3e1e62a
Keywords: checkin-needed
Comment 15•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/01f454a80ce4
Assignee: nobody → mycoolclub
Keywords: checkin-needed
Comment 16•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/01f454a80ce4
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in
before you can comment on or make changes to this bug.
Description
•