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)
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox61 | --- | affected |
People
(Reporter: karlcow, Unassigned)
References
()
Details
(Whiteboard: [webcompat])
Attachments
(1 file)
456 bytes,
text/html
|
Details |
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
Reporter | ||
Updated•6 years ago
|
See Also: → https://webcompat.com/issues/6921
Comment 1•6 years ago
|
||
... and if you deactive and reactivate position property, it jumps to the wrong place again. It's probably an issue of incremental layout.
Comment 2•6 years ago
|
||
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
Comment 3•6 years ago
|
||
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.
Updated•6 years ago
|
Priority: -- → P3
Comment 4•5 years ago
|
||
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.
Webcompat Priority: --- → ?
Comment 5•5 years ago
|
||
See bug 1547409. Migrating whiteboard priority tags to program flags.
Updated•5 years ago
|
Webcompat Priority: ? → P3
Updated•2 years ago
|
Severity: normal → S3
Comment 6•2 days ago
|
||
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.
Webcompat Priority: P3 → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•