216100 - elt.style (mostly?) broken for elements in document fragments

Status: NEW

(Core :: DOM: CSS Object Model, defect, P5)

Description

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

element.style is mostly broken for elements in document fragments -- and
certainly for those in document fragments that have never been in a document. 
(I was discussing this with someone who saw the problem, but I don't have a
testcase.  I can make one eventually, if it's needed, but I wanted to get the
bug on file before I forgot about it.)

The problem is that nsGenericHTMLElement::ParseStyleAttribute does different
things depending on whether the node is in a document and then
nsGenericHTMLElement::SetDocument changes (using ReparseStyleAttribute) the way
we store style attributes when the elements are added into a document.  The
CSSOM code relies on the way they're stored when they're in the document (as a
CSSStyleRuleImpl, rather than a string).

This might be fixable by finding a way to parse the style attribute into a style
rule even when there's no document.  (This risks creating bugs related to our
support for 'Content-Style-Type', but frankly, I think the whole way we store
the style attribute is really a bit iffy as far as the DOM spec is concerned.)

Comment 1

[Boris Zbarsky [:bzbarsky]]

Don't the nodes still have an ownerDocument, and shouldn't we just use that?

Comment 2

[Boris Zbarsky [:bzbarsky]]

One other issue... in XHTML, xml:base kicks in and makes life suck (as in, the
style attr may need to be reparsed as nodes move around in the DOM if we really
care about xml:base totally working).

Comment 3

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

Probably we should keep the string around.  That could help editor as well.  But
probably not now, since I need to fix this to fix a crash without breaking some
editor stuff that worked around this bug by using the DOM Style rule for a style
attribute, which isn't supposed to have a DOM style rule object.

Comment 4

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

Attachment: fixing this would allow us to make these editor changes

I think fixing this bug would allow us to make these changes to editor (which I
need to make to fix bug 218222).

However, the code already uses GetOwnerDocument.  I think the problem may be
that that hasn't been set yet when we're adding attributes to a content node.

Comment 5

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

Actually, I think I can work around the issue.

Comment 6

[Boris Zbarsky [:bzbarsky]]

GetOwnerDocument should work when adding attributes to a content node via
content sinks -- not only do we set mDocument before adding attributes (this may
change), but the content node already has its nodeinfo pointer at that point.

Comment 7

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.