CSS resize property need a transparent resize grip

RESOLVED FIXED

Status

()

Core
CSS Parsing and Computation
RESOLVED FIXED
8 years ago
6 years ago

People

(Reporter: philippe (part-time), Assigned: Neil Deakin)

Tracking

Trunk
x86
Mac OS X
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(9 attachments, 3 obsolete attachments)

(Reporter)

Description

8 years ago
Created attachment 434746 [details]
Screenshot: WebKit vs Gecko

When a background colour is specified for a text area the resize grip (image) shows a white background. It should let the background-colour of the textarea shine through – which is what WebKit does.

(and eventually, the image shouldn't show a border…)

The attached screenshot shows WebKit on top, Gecko at the bottom. The testarea uses the following style:

textarea {
	border:1px solid #090;
	background: #dfd;
	color: #000;
 	-moz-resize: both;
	resize: both;
	}
(Assignee)

Comment 1

8 years ago
Markus, do we have control over the background for native resizers?

A Windows version of this bug is 553752.
I'll check how Webkit does it.
(Assignee)

Comment 4

8 years ago
OK, maybe we should create an image as well, and use it in all or some situations. This might make it easier to support resizers in other directions as well.

This is needed on Mac and Windows Classic at least.

Comment 5

8 years ago
I think an image would make it easier for theme-creators too, so you have my support on that.

Comment 6

8 years ago
What happens when the textarea has scrollbars?
(Reporter)

Comment 7

8 years ago
Created attachment 439897 [details]
screenshot, WebKit with scrollbar

(In reply to comment #6)
> What happens when the textarea has scrollbars?

What WebKit does: the grip has a white background-color (similar to how two scrollbars intersect on a window).
Created attachment 443194 [details]
Transparent Resize Grippies

Top-to-Bottom: Linux, Windows, Mac
Created attachment 443204 [details]
Windows Resize Grippy
Created attachment 443205 [details]
Linux Resize Grippy
Created attachment 443206 [details]
Mac Resize Grippy
(Assignee)

Comment 12

8 years ago
Created attachment 443913 [details] [diff] [review]
patch with transparent images

This patch fixes the following:

This Bug - uses transparent resizer images when a custom background or border is present and no scrollbars are visible
Bug 553752 - resizers in windows classic
Bug 553796 - horizontal and vertical resizers not visible
Bug 558201 - resizer cursor in rtl

I disabled native theme rendering of rtl resizers, due to the -moz-transform conflicting with it, as the transform needs to apply to the non-native image versions.

One minor issue is that the resizer images here are 16x16 but the native resizers are 15x15.
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
(In reply to comment #12)
> One minor issue is that the resizer images here are 16x16 but the native
> resizers are 15x15.

I can resize them to 15x15 if that would be better.
(Assignee)

Comment 14

8 years ago
(In reply to comment #13)
> I can resize them to 15x15 if that would be better.

That would be good. I noticed some minor alignment problems and it might be the cause.
(Assignee)

Comment 15

8 years ago
Created attachment 444128 [details] [diff] [review]
with 15x15 images
(Assignee)

Updated

8 years ago
Attachment #443913 - Attachment is obsolete: true
(Assignee)

Comment 16

8 years ago
Created attachment 444129 [details]
image of resizers in use
(Assignee)

Updated

8 years ago
Attachment #444128 - Flags: review?(roc)
(Assignee)

Comment 17

8 years ago
Comment on attachment 444128 [details] [diff] [review]
with 15x15 images

This patch works well as the image shows. Non-native images are used when custom backgrounds/borders are present, except when the scrollbar is visible on Mac.

I don't like how I had to disable rtl support in the native theme, but the -moz-transform needed for the non-native image conflicts with it. Is there a way around this?

Another option is to include a second set of horizontally flipped images, but it would be nice to also be able to support resizers in the other corners (vertically flipped) if needed.
(Assignee)

Comment 18

8 years ago
I also meant to say that I plan on writing some tests for this as well.
Note that things are worse for Windows Classic, since the default resizer background is not the same as the default textarea background.

Is it perhaps possible to create both scrollcorners and resizers (with the resizer painting over the scrollcorner), but only showing the scrollcorner when at least two of (resizer, hscrollbar, vscrollbar) are visible?
Can the square border (?) around the grippy be removed? I find it rather distracting, and it just seems to hang out into space... 

IE, the screenshots in attachment 444129 [details] look as I'd expect where the background is colored, but not where it's white. Also seems odd for it to be different in those two cases.
(In reply to comment #20)
> Can the square border (?) around the grippy be removed? I find it rather
> distracting, and it just seems to hang out into space... 
> 
> IE, the screenshots in attachment 444129 [details] look as I'd expect where the
> background is colored, but not where it's white. Also seems odd for it to be
> different in those two cases.

I agree it would probably look best to have it without the white box unless there are scrollbars and it doesn't serve any purpose in the non-scrollbar case.
I agree we should lose the box when there are no scrollbars. With scrollbars, I don't mind if the box is there or not.
That either means getting rid of Mac native resizer theming completely and always using the image, or making Mac native theming draw a transparent resizer without box, i.e. drawing the lines manually. The second option is what Colin did in bug 363757.
Carbon native theme drawing doesn't give us the option to draw a transparent resizer; in fact for some Carbon applications you can tell that they're Carbon by looking at their native window resizer (e.g. compare Opera 10.10 and 10.50).
That's unfortunate, but drawing the resizer by hand still seems worth it to me.

Updated

8 years ago
Blocks: 558203

Updated

8 years ago
Blocks: 553752

Updated

8 years ago
Blocks: 563085
(Assignee)

Comment 25

8 years ago
One issue with this patch is that the resizer-bottomend-rtl.xul test fails as it uses:

 <resizer dir="bottomend" style="direction: rtl"/>

but the native theme rtl support has been disabled. Is this something that needs to be supported or is there a better fix here?

Comment 26

8 years ago
I think we still need to support this.  In fact, I'm not so sure what you mean here, are you suggesting that we stop handling resizer elements which have an rtl style?
(Assignee)

Comment 27

8 years ago
(In reply to comment #26)
> I think we still need to support this.  In fact, I'm not so sure what you mean
> here, are you suggesting that we stop handling resizer elements which have an
> rtl style?

No, the problem is that the images use -moz-transform which conflicts with the native theme. See comment 17.
Would this work?
 - make nsNativeThemeCocoa::DrawResizer draw a transparent resizer using the
   hard-coded line drawing approach from attachment 294300 [details] [diff] [review]
 - draw the lines mirrored for RTL
 - always use native theming for resizers on Mac, i.e. #ifndef the whole block
   you add in nsNativeTheme::IsWidgetStyled.
(Assignee)

Comment 29

8 years ago
(In reply to comment #28)
> Would this work?
>  - make nsNativeThemeCocoa::DrawResizer draw a transparent resizer using the
>    hard-coded line drawing approach from attachment 294300 [details] [diff] [review]
>  - draw the lines mirrored for RTL
>  - always use native theming for resizers on Mac, i.e. #ifndef the whole block
>    you add in nsNativeTheme::IsWidgetStyled.

You could do that, but the same would need to be implemented on the other platforms.
Hm, yeah. What about avoiding the transforms altogether and use two separate images for LTR and RTL resizers?
(Assignee)

Comment 31

8 years ago
Created attachment 447526 [details] [diff] [review]
use separate images for ltr and rtl resizers
Attachment #444128 - Attachment is obsolete: true
Attachment #447526 - Flags: review?(roc)
Attachment #447526 - Flags: feedback?(mstange)
Attachment #444128 - Flags: review?(roc)
Attachment #447526 - Flags: feedback?(mstange) → feedback+

Comment 32

8 years ago
Comment on attachment 447526 [details] [diff] [review]
use separate images for ltr and rtl resizers

Does this patch preserve the behavior implemented in bug 240536?
The code looks OK but it's confusing, e.g. on Mac to have the native theme code only draw resizers in scrollframes with scrollbars, but on Windows to have the native theme code only draw resizers when NOT in scrollframes. We need documentation somewhere to explain what our strategy actually is for drawing resizers in different situations on different platforms.
Created attachment 447641 [details]
Screenshot (of current trunk)

(Just pointing out one more example of where transparent grippies should work better. This is on TB+PL, when starring a build.)
(Assignee)

Comment 35

8 years ago
(In reply to comment #33)
> The code looks OK but it's confusing, e.g. on Mac to have the native theme code
> only draw resizers in scrollframes with scrollbars, but on Windows to have the
> native theme code only draw resizers when NOT in scrollframes. We need
> documentation somewhere to explain what our strategy actually is for drawing
> resizers in different situations on different platforms.

Mainly, this is response to comment 22, and to bug 553752. I will add more
clarification.
(Assignee)

Comment 36

8 years ago
Created attachment 451299 [details] [diff] [review]
added more comments

This patch adds more comments to the native widget styling code and updates the resizer css to properly handle the rtl cursor in some cases. I also made a fix so that on Mac, resizers in non-scrollable areas are native themed.
Attachment #447526 - Attachment is obsolete: true
Attachment #451299 - Flags: review?(roc)
Attachment #451299 - Flags: feedback?(ehsan)
Attachment #447526 - Flags: review?(roc)

Comment 37

8 years ago
Comment on attachment 451299 [details] [diff] [review]
added more comments

Here's a screenshot of how the patch looks like for the main window in RTL window:

http://grab.by/4X87

Here's how it looks for the show passwords dialog.

http://grab.by/4X8f

f- based on this.

(The patch looks good on textarea resizer controls though)
Attachment #451299 - Flags: feedback?(ehsan) → feedback-
(Assignee)

Comment 38

8 years ago
Ehsan, the issue with the show passwords dialog is bug 556645 and occurs without this patch as well.

I don't understand what you're indicating in the first image. The image looks correct to me.
Looks correct to me, too - the window resizer is supplied by the OS and its position is not under our control.

Comment 40

8 years ago
(In reply to comment #38)
> Ehsan, the issue with the show passwords dialog is bug 556645 and occurs
> without this patch as well.

Yes.  I'm talking about the right-size resizer.

> I don't understand what you're indicating in the first image. The image looks
> correct to me.

It should be mirrored, and should appear on the left side.
(Assignee)

Updated

8 years ago
Blocks: 558201
(Assignee)

Comment 41

8 years ago
The position of the resizer isn't this bug, so I'm not clear what the objection is here. This bug adjusts only the appearance of the resizer (see bug dependencies) as well as the cursor (the latter is bug 558201).

Comment 42

8 years ago
Comment on attachment 451299 [details] [diff] [review]
added more comments

OK, I guess we can fix the window resizer in another bug.
Attachment #451299 - Flags: feedback- → feedback+

Comment 43

8 years ago
Filed bug 572455 for that.
Comment on attachment 451299 [details] [diff] [review]
added more comments

Presumably this patch only fixes things for the default theme?
(Assignee)

Comment 45

8 years ago
(In reply to comment #44)
> (From update of attachment 451299 [details] [diff] [review])
> Presumably this patch only fixes things for the default theme?

Yes, are there changes you think could be made?
(Assignee)

Comment 46

8 years ago
http://hg.mozilla.org/mozilla-central/rev/d0801f21095f
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
(Assignee)

Updated

8 years ago
Blocks: 553796

Updated

8 years ago
Depends on: 573486
(In reply to comment #45)
> (In reply to comment #44)
> > (From update of attachment 451299 [details] [diff] [review])
> > Presumably this patch only fixes things for the default theme?
> Yes, are there changes you think could be made?
Well, rather than giving the native theme code "insider" knowledge of the scroll frame, my suggestion would have been to make the resizer always transparent and display a scrollcorner element underneath it when either scrollbar is visible.

Updated

8 years ago
No longer depends on: 573486

Updated

8 years ago
Depends on: 573486

Updated

8 years ago
No longer blocks: 602007

Updated

6 years ago
Depends on: 834724
You need to log in before you can comment on or make changes to this bug.