How to reproduce: 1. Open this demo page: http://www.456bereastreet.com/lab/text-overflow-ellipsis-firefox/ Actual Result: dots appear over drop-down menu Expected Result: Firefox should render just like other browsers Article regarding this bug: http://www.456bereastreet.com/archive/201305/firefox_and_the_magical_text-overflowellipsis_z-index/

I see this also. Happens regardless if HWA is on or off. Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20130624 Firefox/24.0

I see the issue on Firefox 21 and Nightly 24 on Ubuntu and Windows 7. I tried Chromium, Chrome, and IE and none of those browsers show the issue.

Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/56854b8cf1a6 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110622 Firefox/7.0a1 ID:20110622152133 Bad: http://hg.mozilla.org/mozilla-central/rev/48e72227c2fa Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110623 Firefox/7.0a1 ID:20110623030811 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=56854b8cf1a6&tochange=48e72227c2fa Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/e302cef502f6 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110622 Firefox/7.0a1 ID:20110622051524 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/efad576d17ce Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110622 Firefox/7.0a1 ID:20110622111924 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e302cef502f6&tochange=efad576d17ce Suspected: Bug 312156

I can confirm this bug on Firefox 36. This bug also occurs when a <string> is used to represent clipped text. Test case: http://codepen.io/7studio/pen/WbyQZg

The duplicate bug 1252872 provides a much simplified testcase: attachment 8725699 [details]. [Also, I'm clarifying this bug's title to remove mention of "drop-down menu", since there's nothing specific to menus or drop-downs here.]

I'm looking into this since it's biting me in some content I want to write. In bug 748646, we add the display item for an ellipsis into the PositionedDescendants() list, which I assume is what is causing the bad interactions here. Why do we put it there, rather than in the Content() list? Are there cases where doing https://hg.mozilla.org/try/rev/9c4f0fcd3d892d5165c765dc79c5fac812ea8bf5 would be wrong?

punting needinfo to mats, since worked more on 'ellipsis' IIRC & he was the author on that PositionedDescendants() insertion (part 1 on bug 748646 -- I just shepherded it in for him & addressed a few review comments).

There's some discussion of this in bug 735898 comment 52 and forward. I think we sorted Content() in content-order at that time which put all the markers at the bottom, below backgrounds of inline children for example, which is why we chose bottom of PositionedDescendants() instead. The suggested patch should work, but only if we never ever sort the Content() list. I'm guessing that we don't at the moment, so I guess this is fine for now...

I can add a comment there to point out that things would break if we start sorting the Content() list, and a regression test will catch it if we ever do.

Pushed by cmccormack@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/176554242eb3 Fix sorting of text-overflow:ellipsis relative to positioned content. r=mats

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/14976 for changes under testing/web-platform/tests

Upstream PR was closed without merging