If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

NEW
Unassigned

Status

()

Core
Layout: Form Controls
--
enhancement
3 years ago
3 years ago

People

(Reporter: mats, Unassigned)

Tracking

({testcase})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
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
(Reporter)

Comment 1

3 years ago
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.
(Reporter)

Comment 2

3 years ago
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?
(Reporter)

Comment 3

3 years ago
Am I on the right track with the style context hierarchy as I set it up in
CreateAnonymousContent here?  Or suggest alternatives?  Thanks.
Flags: needinfo?(dbaron)
Flags: needinfo?(cam)
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?
Flags: needinfo?(dbaron)
Flags: needinfo?(cam)
You need to log in before you can comment on or make changes to this bug.