944246 - make nsComputedDOMStyle return the right style when pseudo-elements like ::-moz-progress-bar are passed in and user action pseudo-classes apply

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect, P4)

Description

[Cameron McCormack (:heycam)]

Once bug 922669 lands, user action pseudo-classes can be applied to certain pseudo-elements.  nsComputedDOMStyle doesn't pass in the anonymous content for the pseudo-element, so it can't check if :hover etc. applies, but it should.

Comment 1

[Cameron McCormack (:heycam)]

Attachment: patch

https://tbpl.mozilla.org/?tree=Try&rev=fb1d9f7e7da8

Comment 2

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8340174 [details] [diff] [review]
patch

I really wish we could just have:

  virtual mozilla::dom::Element* GetPseudoElement(nsCSSPseudoElements::Type aType);

but I guess most of those frames are storing nsIContent?  :(

r=me, but maybe file a followup to fix that?

Comment 3

[Cameron McCormack (:heycam)]

(In reply to Boris Zbarsky [:bz] from comment #2)
> but I guess most of those frames are storing nsIContent?  :(
> 
> r=me, but maybe file a followup to fix that?

They are storing nsIContent pointers, but I didn't check to see whether all of them are really Elements.  They probably are.  My thinking though was that given nsIAnonymousContentCreator is geared towards creating nsIContent*s, there's a chance a frame will create e.g. a text node.  Still, it's not likely that we'll want the pseudo type that we pass in there to match something that isn't an element, so I think it would be OK to change it.

Comment 4

[Cameron McCormack (:heycam)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/01b220863153

Comment 5

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/01b220863153