Created attachment 8698690 [details] Engadget Screenshot.png User Agent: Mozilla/5.0 (Android 6.0.1; Mobile; rv:46.0) Gecko/46.0 Firefox/46.0 Build ID: 20151215030221 Steps to reproduce: Connect to Engadget.com on Firefox for Android Actual results: Article images (usually only after scrolling down ~5 articles) overlap the titles Expected results: Titles (and white background) should be on top of images Renders fine on competing browsers and FF desktop
I can't reproduce this on my GS4 on a local build. Which version of Firefox are you running? On which device?
Running the latest nightly on a HTC One M8 (VZW) under the stock 5.0.? ROM as well as the latest CM13.
I can reproduce this on a Nexus 5x. Might be a website bug. Pinging MikeT to have a look
Created attachment 8699117 [details] engadget.png Also reproduces for me on a Nexus 6P. Taking a closer look...
And reproduces on a Moto G (dPR of 2), and on Desktop w/ a mobile-sized viewport. Gonna try to reduce, I don't see anything especially funky in the site. Possibly a core layout bug.
OK, so here's the reduced test case. The text should be on stacked on top of the bearded guy, not partially cut off and under: http://jsbin.com/jiyejolepi/1/edit?html,css,output It seems like Edge agrees with our rendering, so I wonder if this is a WebKit quirk that the designers are relying on? Although Opera Presto does the same thing that Chrome does. Daniel, does anything jump out at you as to what the issue might be?
Flags: needinfo?(miket) → needinfo?(dholbert)
Created attachment 8699234 [details] testcase 1 Here's a further-reduced version of Mike's textcase. In Firefox, the gray div renders in front. In Chrome, the orange div renders in front. A few notes on this testcase: - The gray div is inside of a "position:relative; z-index:1" inline-level element. If I remove that styling, Chrome is unchanged & Firefox changes to match Chrome's rendering. - The orange div has "position:relative" (and doesn't specify a z-index). If I remove that styling, Chrome changes to match Firefox's rendering.
(Edge agrees with us on my 'testcase 1', too.)
Created attachment 8699239 [details] testcase 2 Here's a slightly more elaborate testcase, with a background & some text added to the span (the thing that has "z-index" set). Chrome agrees with us that *the span's own text and background* do render in front -- honoring the span's "z-index". But they don't agree with us about the stacking order of the div child of the span. I need to review the description at http://www.w3.org/TR/CSS21/zindex.html#each-box to be sure about who's matching the spec here...
The spec text is a bit iffy (largely because there's a block-in-inline split here, and I'm not immediately sure if the block-child counts as part of "each line box that the [inline] element is in", from step 6). From a bit more bugzilla-searching, I think this is bug 644198, and bz's last comment there (bug 644198 comment 6) describes my confusion as well. Marking as depends-on that bug, for now. If we want to convert this bug here to a Tech Evang bug, there's likely a CSS tweak that'd help here and avoid this spec-ambiguity. (e.g. dropping the "z-index" declaration on the parent of the <img>, since they don't actually want that parent to be in front of the text)
Depends on: 644198
Engadget appears to have updated on their end. The underlying cause of the "bug" is still there, but it seems unclear that it is truely an issue. Marking it as resolved, but MWE still disagree with other browsers. Feel free to open back up if someone deems it important.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.