Open Bug 1449079 Opened 6 years ago Updated 2 days ago

PNG background-image icon not positioned at the right place after first rendering

Categories

(Core :: Layout: Positioned, defect, P3)

61 Branch
Unspecified
All
defect

Tracking

()

Tracking Status
firefox61 --- affected

People

(Reporter: karlcow, Unassigned)

References

()

Details

(Whiteboard: [webcompat])

Attachments

(1 file)

This is a spin off of https://webcompat.com/issues/6921

Steps to reproduce


    Navigate to: http://www.priceminister.com/offer/buy/674819595/ecran-complet-pour-iphone-5c-noir-vitre-tactile-ecran-lcd-sur-chassis-outils.html?rtg=431479671ab02be8a29218cbe4b674cf
    Observe “Ajounter au panier” (“Add to cart”) button.

Actual
The icon is shifted toward the bottom.

Expected 
The icon is aligned with the text.

```css
.shippingBtn .cartIcon::before {
	content: '';
	position: absolute;
	display: block;
	width: 27px;
	height: 35px;
	left: -35px;
	overflow: hidden;
	margin-top: 5px;
	background-image: url(images/add-to-cart-70.png);
	background-repeat: no-repeat;
	background-size: 27px 35px;
}
```

If I modify or just deactivate and reactivate any css values in the inspector tool related to width/height, the icon takes its right place.

(So I guess anything which triggers a repaint? of the page.)

In Chrome the icon is at the right place.

This has been the case with Firefox from 55 to 61 at least
... and if you deactive and reactivate position property, it jumps to the wrong place again.

It's probably an issue of incremental layout.
Specifically, I think it is related to how hypothetical box is computed.

I'm not familiar with this part of code, but my guess is that, when the ::before pseudo-element is initially laid out, since the text hasn't been placed, the container `.ui-btn-inner` and all its descendants have a height of zero, and thus the pseudo-element is somehow assigned a position related to its parent `.cartIcon` by 5px. However, after the text after is laid, the height of the container grows to 40px (due to line-height), but we didn't update the hypothetical box of the pseudo-element.

Since tweaking width/height triggers reflow on the pseudo-element, maybe we correctly update the hypothetical box at that moment, while tweaking position property of pseudo-element causes us to reframe its parent `.cartIcon`, and thus relayout that whole element and trigger the bug again.

So this isn't really an issue of incremental layout, it is a problem of how hypothetical box of absolutely-positioned element is calculated and updated.
Component: Layout → Layout: R & A Pos
Attached file testcase
Tried to construct a testcase. Actually it makes me a bit confused, because to produce this, it needs to make an inline element also position:relative, but it seems that is not supposed to affect the positioning of absolutely-positioned element inside it given the result after tweaking width/height?

This makes me suspect that it is just a small mismatch somewhere on which container element to base, rather than something more fundamental.
Priority: -- → P3

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

Webcompat Priority: --- → ?

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

Webcompat Priority: ? → P3
Severity: normal → S3

The linked webcompat issue https://webcompat.com/issues/6921 is not reproducible anymore as the button design has changed, resetting webcompat priority. The difference in the test case is still present.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: