554810 - CSS resize property need a transparent resize grip

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[philippe (part-time)]

Attachment: 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;
	}

Comment 1

[Neil Deakin]

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

A Windows version of this bug is 553752.

Comment 2

[Markus Stange [:mstange]]

I'll check how Webkit does it.

Comment 3

[Markus Stange [:mstange]]

They use an image:
http://trac.webkit.org/export/56518/trunk/WebCore/Resources/textAreaResizeCorner.tiff

Comment 4

[Neil Deakin]

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

[d]

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

Comment 6

[[e-mail]]

What happens when the textarea has scrollbars?

Comment 7

[philippe (part-time)]

Attachment: 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).

Comment 8

[Stephen Horlander [:shorlander]]

Attachment: Transparent Resize Grippies

Top-to-Bottom: Linux, Windows, Mac

Comment 9

[Stephen Horlander [:shorlander]]

Attachment: Windows Resize Grippy

Comment 10

[Stephen Horlander [:shorlander]]

Attachment: Linux Resize Grippy

Comment 11

[Stephen Horlander [:shorlander]]

Attachment: Mac Resize Grippy

Comment 12

[Neil Deakin]

Attachment: 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.

Comment 13

[Stephen Horlander [:shorlander]]

(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.

Comment 14

[Neil Deakin]

(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.

Comment 15

[Neil Deakin]

Attachment: with 15x15 images

Comment 16

[Neil Deakin]

Attachment: image of resizers in use

Comment 17

[Neil Deakin]

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.

Comment 18

[Neil Deakin]

I also meant to say that I plan on writing some tests for this as well.

Comment 19

[[e-mail]]

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?

Comment 20

[Justin Dolske [:Dolske]]

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.

Comment 21

[Stephen Horlander [:shorlander]]

(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.

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 23

[Markus Stange [:mstange]]

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).

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That's unfortunate, but drawing the resizer by hand still seems worth it to me.

Comment 25

[Neil Deakin]

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

[(no longer active)]

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?

Comment 27

[Neil Deakin]

(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.

Comment 28

[Markus Stange [:mstange]]

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.

Comment 29

[Neil Deakin]

(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.

Comment 30

[Markus Stange [:mstange]]

Hm, yeah. What about avoiding the transforms altogether and use two separate images for LTR and RTL resizers?

Comment 31

[Neil Deakin]

Attachment: use separate images for ltr and rtl resizers

Comment 32

[(no longer active)]

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?

Comment 33

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 34

[Justin Dolske [:Dolske]]

Attachment: 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.)

Comment 35

[Neil Deakin]

(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.

Comment 36

[Neil Deakin]

Attachment: 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.

Comment 37

[(no longer active)]

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)

Comment 38

[Neil Deakin]

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.

Comment 39

[Markus Stange [:mstange]]

Looks correct to me, too - the window resizer is supplied by the OS and its position is not under our control.

Comment 40

[(no longer active)]

(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.

Comment 41

[Neil Deakin]

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

[(no longer active)]

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

OK, I guess we can fix the window resizer in another bug.

Comment 43

[(no longer active)]

Filed bug 572455 for that.

Comment 44

[[e-mail]]

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

Presumably this patch only fixes things for the default theme?

Comment 45

[Neil Deakin]

(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?

Comment 46

[Neil Deakin]

http://hg.mozilla.org/mozilla-central/rev/d0801f21095f

Comment 47

[[e-mail]]

(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.

Comment 48

[Cem]

Okay, so I stumbled upon an issue with material-components-web. And they referred me to this bugreport.

https://github.com/material-components/material-components-web/issues/6783

This seems to be an issue still smh?

Apparently they use something like:

<style>
  #resize {
    width: 250px;
    height: 56px;
    border: 1px solid black;
    background: darkgray;
    resize: both;
    overflow: hidden;
  }
</style>
<div id="resize"></div>

And then it seems to still use the old intransparent handler on "some combinations of linux and firefox".

Demo: https://codepen.io/rebootl/pen/ZEpdpJx

So I tested on Ubuntu 20.04, firefox 84.0.2 aswell as Arch Linux, firefox 84.0.2, and it happened in both cases.

Thx.