STR: load data:text/html,<input type=button accesskey=C value=Cancel> EXPECTED RESULTS "C" is underlined I think we need to support this so we can use HTML buttons instead of XUL buttons in places like this: http://mxr.mozilla.org/mozilla-central/source/browser/components/sessionstore/content/aboutSessionRestore.xhtml#61
Created attachment 8558831 [details] [diff] [review] wip part 1 This creates 3 anon content nodes instead of one: "" <span>"C"</span> "ancel" And it resolves a CSS pseudo :-moz-accesskey on the <span>. This works fine the way I set up the style contexts in CreateAnonymousContent - here's an edited frame dump: ButtonControl(input)(0) [content=7f6168333980] [sc=7f6164febbe8]< Block(input)(0) [content=7f6168333980] [sc=7f6164ea7a48:-moz-button-content]< Text(-1)"" [content=7f6164ff1e50] [sc=7f6164ea8190:-moz-non-element^7f6164febbe8] Inline(span) [content=7f6164ff1ee0] [sc=7f6164ea7f80:-moz-accesskey^7f6164febbe8]< Text(0)"C" [content=7f6164ff1f70] [sc=7f6164ea80e8:-moz-non-element] > Text(-1)"ancel" [content=7f6164ff1d30] [sc=7f6164ea8190:-moz-non-element^7f6164febbe8] > > As you can see, the style context parent on the anon content frames is the ButtonControl style context (7f6164febbe8). The "C" is underlined. But the underline disappears after hovering the button: ButtonControl(input)(0) [content=7f6168333980] [sc=7f6164ea8190]< Block(input)(0) [content=7f6168333980] [sc=7f6164fe9c70:-moz-button-content]< Text(-1)"" [content=7f6164ff1e50] [sc=7f6164ea80e8:-moz-non-element^7f6164ea8190] Inline(span)(-1) [content=7f6164ff1ee0] [sc=7f6164ea7f80:-moz-accesskey]< Text(0)"C" [content=7f6164ff1f70] [sc=7f6164ea80e8:-moz-non-element^7f6164ea8190] > Text(-1)"ancel" [content=7f6164ff1d30] [sc=7f6164ea80e8:-moz-non-element^7f6164ea8190] > > Now the <span>'s style context parent is the parent (:-moz-button-content) frame's. And the text nodes all share the same style context. This doesn't seem right.
Created attachment 8558834 [details] [diff] [review] wip part 2 So when reparenting the style contexts for the hover style change, we get to nsFrame::DoGetParentStyleContext -> GetCorrectedParent -> CorrectStyleParentFrame, which I hacked like this to make it work (same style context hierarchy as was set up in CreateAnonymousContent) This triggers assertions in other cases so I'm quite sure it's not correct in for native anonymous content in general. The question is - what is correct in general?
Am I on the right track with the style context hierarchy as I set it up in CreateAnonymousContent here? Or suggest alternatives? Thanks.
It seems odd to say that the usual rules don't apply just because we're in a native-anonymous subtree. I don't see the rationale for that. In general, nsFrame::DoGetParentStyleContext should produce the same results as the initial construction of the frame tree. I presume that's not happening, which is leading the restyle to parent the style context for the text that should be underlined to something other than the anonymous span that's doing the underlining? What you're doing seems rather like the way pseudo-elements stylistically. I think it should be a pseudo-element rather than an anonymous box. I think the primary difference between pseudo-elements and anonymous boxes is that anonymous boxes are transparent to inheritance (and their child frames inherit from the non-anonymous-box parent). I believe it was the original reason for separating them in bug 147887 and bug 147888. That could definitely be documented better, though. (Any chance I could get you to add comments to nsCSSAnonBoxes / nsCSSPseudoElements?) Also, is there a plan for standardizing this?
4 years ago
You need to log in before you can comment on or make changes to this bug.