Closed Bug 598090 Opened 9 years ago Closed 9 years ago

Sync up the list of white-listed HTML tags and attributes in the sanitizing fragment sink with the HTML5 spec

Categories

(Core :: DOM: Core & HTML, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla2.0b7
Tracking Status
blocking2.0 --- final+
blocking1.9.2 --- .11+
status1.9.2 --- .11-fixed
blocking1.9.1 --- .14+
status1.9.1 --- .14-fixed

People

(Reporter: Ehsan, Assigned: Ehsan)

References

Details

(Keywords: html5, Whiteboard: [tb31needed])

Attachments

(1 file, 1 obsolete file)

The list of tags and attributes that we use for the white-list used in the sanitizing fragment sink is out of date.  I'm filing this bug so that I can go through it and add any missing HTML5 tags/attrs in order for us to comply with HTML5.
blocking1.9.2: --- → ?
blocking2.0: --- → ?
Attached patch Patch (v1) (obsolete) — Splinter Review
Attachment #476876 - Flags: review?(bzbarsky)
Attachment #476876 - Flags: approval2.0?
Is @autofocus safe?

Is @form safe if it points outside the editable area?  What about the other @form* attributes?

What about @radiogroup?

Not sure what @pattern, @optimum, @scoped really do.
(In reply to comment #3)
> Is @autofocus safe?

Yes, it doesn't run any scripts.

> Is @form safe if it points outside the editable area?  What about the other
> @form* attributes?

Hmm, good point.  I think we should not allow those attributes...  Will submit a new patch soon.

> What about @radiogroup?

Looks safe to me.

> Not sure what @pattern, @optimum, @scoped really do.

@pattern allows one to specify the valid patterns of text that an input control accepts.  @optimum allows one to specify the optimum value in the gague for a <meter> element.  @scoped allows one to specify that a <style> element only affects its parent subtree.  We don't generally allow the style element, so this is useless most of the time, except when we specifically allow the paranoid fragment sink to accept <style> elements, which would cause this to come to play.
Attached patch Patch (v2)Splinter Review
With @form* attributes removed.
Attachment #476876 - Attachment is obsolete: true
Attachment #476891 - Flags: review?(bzbarsky)
Attachment #476891 - Flags: approval2.0?
Attachment #476876 - Flags: review?(bzbarsky)
Attachment #476876 - Flags: approval2.0?
Whiteboard: [tb31needs]
Comment on attachment 476891 [details] [diff] [review]
Patch (v2)

r=me
Attachment #476891 - Flags: review?(bzbarsky) → review+
Attachment #476891 - Flags: approval2.0? → approval2.0+
Blocks: 596300
blocking1.9.1: --- → ?
blocking1.9.1: ? → .14+
blocking1.9.2: ? → .11+
http://hg.mozilla.org/mozilla-central/rev/0fb87b689b2c
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b7
Attachment #476891 - Flags: approval1.9.2.11?
Attachment #476891 - Flags: approval1.9.1.14?
Comment on attachment 476891 [details] [diff] [review]
Patch (v2)

a=LegNeato for 1.9.2.11 and 1.9.1.14
Attachment #476891 - Flags: approval1.9.2.11?
Attachment #476891 - Flags: approval1.9.2.11+
Attachment #476891 - Flags: approval1.9.1.14?
Attachment #476891 - Flags: approval1.9.1.14+
Is there going to be an automated test included with this?
(In reply to comment #11)
> Is there going to be an automated test included with this?

Not really.  The benefit of automated tests here is very low, and the cost of creating one is actually really high (the number of possible combinations to test is scary).
I know. Imagine having to test them all by hand because there is no automated test.
As a way to test it, you can open a tab with data:text/html,<input autofocus value=test>, and another with http://www.mozilla.org/editor/midasdemo/.  In the former, click the body, Cmd+A and Cmd+C, then go to midasdemo and paste inside the editable area, then click View HTML Source and make sure that the autofocus attribute is there.
Whiteboard: [tb31needs] → [tb31needed]
blocking2.0: ? → final+
You need to log in before you can comment on or make changes to this bug.