Open Bug 1497959 Opened 3 years ago Updated 8 months ago

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


(Core :: Web Painting, defect, P3)




Webcompat Priority ?
Tracking Status
firefox62 --- affected
firefox63 --- affected
firefox64 --- affected


(Reporter: khasan222, Unassigned)



(Whiteboard: [webcompat])


(1 file)

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

Steps to reproduce:

I opened this codepen 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
I discovered this working on
Also here is that link, since I can't edit the description of the bug
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.
Ever confirmed: true
Flags: needinfo?(kdubost)
Product: Firefox for Android → Core
Hardware: Unspecified → All
Whiteboard: [webcompat]
Version: Firefox 62 → Trunk
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.

.logo img {
	height: 100%;
	width: 100%;

The nesting context is 

.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
Flags: needinfo?(kdubost)

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

.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.
Moving to layout.
Component: General → Layout
See Also: → 1500300
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.
Assignee: nobody → 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.
Emilio: Should we re-categorize this bug to a graphics component?
Flags: needinfo?(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.
Assignee: emilio → nobody
Component: Layout → Web Painting
Flags: needinfo?(emilio)
Summary: clip-path: inset(0 0) cuts off content if it is too long → clip-path: inset(0 0) cuts off content if it is too long when not using WebRender

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

Webcompat Priority: --- → ?

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

Priority: -- → P3
Webcompat Priority: ? → ---
Webcompat Priority: --- → ?
You need to log in before you can comment on or make changes to this bug.