Closed Bug 886716 Opened 6 years ago Closed 9 months ago

Stacking order is too high for text-overflow:ellipsis (it jumps to the foreground, as if it had z-index set)


(Core :: Layout: Block and Inline, defect)

Windows 7
Not set



Tracking Status
firefox66 --- fixed


(Reporter: zlip.792, Assigned: heycam)


(Blocks 1 open bug, )


(Keywords: regression)


(1 file)

How to reproduce:

1. Open this demo page:

Actual Result:
dots appear over drop-down menu

Expected Result:
Firefox should render just like other browsers

Article regarding this bug:
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.
Ever confirmed: true
Regression window(m-c)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110622 Firefox/7.0a1 ID:20110622152133
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110623 Firefox/7.0a1 ID:20110623030811

Regression window(m-i)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110622 Firefox/7.0a1 ID:20110622051524
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110622 Firefox/7.0a1 ID:20110622111924

Suspected: Bug 312156
Blocks: 312156
I can confirm this bug on Firefox 36.
This bug also occurs when a <string> is used to represent clipped text.

Test case:
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.]
Summary: Dots appearing over drop-down menu using text-overflow:ellipsis z-index → Stacking order is too high for text-overflow:ellipsis (it jumps to the foreground, as if it had z-index set)
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 would be wrong?
Assignee: nobody → cam
Component: CSS Parsing and Computation → Layout: Block and Inline
Flags: needinfo?(dholbert)
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).
Flags: needinfo?(dholbert) → needinfo?(mats)
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()

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...
Flags: needinfo?(mats)
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
Fix sorting of text-overflow:ellipsis relative to positioned content. r=mats
Created web-platform-tests PR for changes under testing/web-platform/tests
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
QA Whiteboard: [good first verify]
Upstream PR was closed without merging

I have reproduced this bug with Nightly 25.0a1 (2013-06-25) on Windows 10, 64 Bit. The fix of this bug is verified with latest Beta 66.0b4!

Build ID : 20190131191227
User Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

QA Whiteboard: [good first verify] → [good first verify] [bugday-20190130]
Duplicate of this bug: 1519600
You need to log in before you can comment on or make changes to this bug.