Closed Bug 418214 Opened 15 years ago Closed 15 years ago

[FIX]DOMParser modifies @style attribute when parsing a node in XHTML namespace

Categories

(Core :: XML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: sjoerdmulder, Assigned: bzbarsky)

References

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: 

Firefox seems to modify the style attribute when parsing XML. Because of this, it can’t be set using {} in XSLT. In the example attachted

Reproducible: Always

Steps to Reproduce:
1. Open the testcase
2. See the result from the parse / serialize in the textarea to be different
3. See how the middle box misses the red bottom-border
Actual Results:  
Middle box misses the red bottom-border

Expected Results:  
In Safari / Opera the testcase works as expected, all the 3 boxes should have a red bottom-border
Attached file Testcase
What's happening is that we don't keep the source of the style attribute but parse it as CSS, |border-bottom: {$border}| is not valid CSS so it gets dropped. See also this warning in the console:

Warning: Error in parsing value for property 'border-bottom'.  Declaration dropped.
Source File: https://bugzilla.mozilla.org/attachment.cgi?id=304017
Line: 0
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Yes, i get that but when it's XML it should not parse the style attribute as CSS because the @style attribute doesnt mean anything (for XML)
(In reply to comment #3)
> Yes, i get that but when it's XML it should not parse the style attribute as
> CSS because the @style attribute doesnt mean anything (for XML)

But it means something for XHTML ;-). Not sure how to fix this without bloat for the majority of cases where we don't need the original attribute value.
Until modified every attribute should always retain its source specified value, including style=""... Doing otherwise sounds like a violation of the DOM.
> Until modified every attribute should always retain its source specified value,

We have an existing (possibly wontfix) bug on this.  The memory bloat is a very real issue here.  Note that there are lots of other DOM attributes that also get normalized.

For this particular case, I think one simple solution would be to not parse the style attribute if the document is a data document.  In that case, we don't need the parsed value for anything.  If the script adopts and then inserts the node into a non-data document, we'll reparse the attribute.  If the script gets .style, we'll parse the attribute.
Attached patch Like so, saySplinter Review
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #304058 - Flags: superreview?(peterv)
Attachment #304058 - Flags: review?(peterv)
Summary: DOMParser modifies @style attribute when parsing a node in XHTML namespace → [FIX]DOMParser modifies @style attribute when parsing a node in XHTML namespace
Comment on attachment 304058 [details] [diff] [review]
Like so, say

Sweet!

>+   * string.  If aForce is true, will reparse even if we're in a data document.

s/aForce/aForceInDataDoc/
Attachment #304058 - Flags: superreview?(peterv)
Attachment #304058 - Flags: superreview+
Attachment #304058 - Flags: review?(peterv)
Attachment #304058 - Flags: review+
Comment on attachment 304058 [details] [diff] [review]
Like so, say

This should be pretty safe and help a number of scripting use cases.
Attachment #304058 - Flags: approval1.9?
Attachment #304058 - Flags: approval1.9? → approval1.9+
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
See Also: → 1281670
You need to log in before you can comment on or make changes to this bug.