1497959 - clip-path: inset(0 0) cuts off content if it is too long when not using WebRender

Status: RESOLVED WORKSFORME

(Core :: Web Painting, defect, P3)

Description

[Khalah Jones-Golden]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0

Steps to reproduce:

I opened this codepenhttps://codepen.io/panda01/pen/xydRvG in firefox for android, and then scrolled all the way to the bottom.


Actual results:

The content disappears from the screen.


Expected results:

The content should still be there along with the fixed elements

Comment 1

[Khalah Jones-Golden]

I discovered this working on https://christopher-tierney.com/apotheke-la/

Comment 2

[Khalah Jones-Golden]

Also here is that link, since I can't edit the description of the bug https://codepen.io/panda01/pen/xydRvG

Comment 3

[Bogdan Surd, QA [:bsurd, NI]]

Thank you for the report!

Tested in Chrome and FF (Nightly, Beta & Release).

The issue is reproducible for both mobile and desktop platforms and looks like a web compatibility problem since Chrome displays the page properly.

Ni Karl as well to have a look over this.

Comment 4

[Karl Dubost💡 :karlcow]

Attachment: firefox left, chrome right

Chrome and Firefox display the page differently. We do not know yet who is right/wrong.
Let's see. The text is not the same too. See the screenshot.

The image is 417px x 163px
but is resized 
to  128px x 50px in Firefox
and 417px x 50px in Chrome.

```css
.logo img {
	height: 100%;
	width: 100%;
}
```

The nesting context is 

```css
.logo {
	position: fixed;
	top: 30px;
	left: 50%;
	transform: translateX(-50%);
	height: 50px;
}
```

* 127.9px x 50px in Firefox
* 417px x 50px in Chrome

if we remove the `width:100%`, the rendering is the same in Firefox and Chrome.

This should probably be a separate bug if it's not already a known issue in either Chrome or Firefox.

Let's move onto the clip-path

Comment 5

[Karl Dubost💡 :karlcow]

Firefox:

* html  898 x 21935
* body  882 x 21935
* .main 882 x 20720

Chrome (width doesn't matter that much):

* html  898 x 21950
* body  882 x 21934
* .main 883 x 20720

So more or less the same.
But starting the 11th ".project" div, images just disappear.

Activating/deactivating the clip-path makes the images disappear/appear. What a weird issue.

```css
.main {
	background-color: #fff;
	clip-path: inset(0 0);
}

.project {
	display: flex;
}

.project + .project {
	padding-bottom: 400px;
}

.project > img {
	object-fit: cover;
}
```

I have the feeling that the test case could be even reduced a bit more. It seems like clip-path after a certain height makes everything disappear.

Comment 6

[Karl Dubost💡 :karlcow]

Moving to layout.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Fun one, thank you! I think this is probably more graphics (layout doesn't do clipping).

I was looking for stuff to fix in WebRender and you just gave me a nice crashtest too :-).

I'll take a look at this while I'm looking at bug 1500300, so assigning tentatively at least.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Yeah, so this is fixed in WebRender now via bug 1500575 and similar.

What's happening is that this is probably hitting texture size limits, since Gecko builds a clip mask and masks it over the content.

Comment 9

[Sean Voisen (:svoisen)]

Emilio: Should we re-categorize this bug to a graphics component?

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Ah, right, Web Painting is no longer under Layout...

I vote for web painting. What should happen here is probably implementing the same optimizations I implemented in bug 1500300 on the Gecko display list.

Comment 11

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 12

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 13

[Dennis Schubert [:denschub]]

"when not using WebRender" is a condition that should no longer apply in regular use - closing this.