Open Bug 305585 Opened 15 years ago Updated 3 years ago
::-moz-selection does not allow 'outline'
Mozilla currently only supports 'background' and 'color' for the ::selection pseudo-element as properties. Selectors defines that 'cursor' and 'outline' should apply as well. The bug for 'cursor' has been filed I believe. This one is for 'outline'.
Assignee: dbaron → nobody
QA Contact: ian → style-system
What about text-outline bug 470547 ? Which is right for selection or maybe both, one for the text and the other for the box?
I took a shot at this and got it mostly working, but I can't get the drawn outline(s) to *not* be tightly clipped to what looks like 1px outside the content box of each nsTextFrame (except when I select text on multiple lines, then it sometimes will draw at least some of the top/bottom outline edges which are common between the lines with selections). I tried two approaches: 1. changing nsTextFrame::PaintTextWithSelectionColor to also make calls to nsCSSRendering::PaintOutline (which I altered to use the nsStyleContext of the pseudo-element). 2. changing nsTextFrame::BuildDisplayList to make calls to aLists.Outlines()->AppendNewToTop with the selection outlines' rects (a much more complex approach). I also tried sending Inflated() rects and the parent frame of the nsTextFrame to PaintOutline, as well as disabling the various PushClip methods in the Skia draw target class, but I can't quite figure out what's causing this clipping effect. Is this something that's just inherent to nsTextFrames, being inline boxes? If so, would I have to draw the text frame's selection outlines as part of their parent frame's DisplayBorderBackgroundOutline method (or something along those lines)?
That's presumably the hard part. There are probably relatively deep assumptions that selection drawing fits within the visual overflow rect (see nsIFrame::GetVisualOverflowRect, nsIFrame::UpdateOverflow, etc.) of the text frames and/or the bounds of the relevant display list items (see nsDisplayItem::GetBounds) which are generally derived from the visual overflow rect. So presumably (assuming that's correct) you'd either need to set up a mechanism for selection to change overflow areas (which ought to be doable without reflow -- since although UpdateOverflow can fail and require reflow, I think it shouldn't do that fo changes to the visual overflow area only, and we ought to be able to guarantee that, although we might not guarantee it today), or do something to avoid whatever assumptions are being broken.
You need to log in before you can comment on or make changes to this bug.