1129221 - Add support for styling @accesskey on HTML <input type=button>

Status: NEW

(Core :: Layout: Form Controls, enhancement)

Description

[Mats Palmgren (inactive)]

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

Comment 1

[Mats Palmgren (inactive)]

Attachment: 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.

Comment 2

[Mats Palmgren (inactive)]

Attachment: 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?

Comment 3

[Mats Palmgren (inactive)]

Am I on the right track with the style context hierarchy as I set it up in
CreateAnonymousContent here?  Or suggest alternatives?  Thanks.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?