Created attachment 62095 [details] Patch

The another option is to teach HTMLElementStack how to do this, but it doesn't have a notion of Document, so that seemed like it was too low a layer. Similarly, we could do this work in HTMLTreeBuilder, but there are a lot more call sites, so that seemed too high level.

Comment on attachment 62095 [details] Patch This is definitely the right layer. I hate that we duplicate this is parsing fragment state partially in the fragment scripting enum.

Comment on attachment 62095 [details] Patch Clearing flags on attachment: 62095 Committed r63762: <http://trac.webkit.org/changeset/63762>

All reviewed patches have been landed. Closing bug.

> This is definitely the right layer. I hate that we duplicate this is parsing fragment state partially in the fragment scripting enum. Can we make the enum more awesome to include this bit? It does seem really redundantly redundant.

The enums are semantically different, I think. One is used throughout the code to mean fragment stuff. I think that the parser should probably have a separate state machine enum and know how to convert to the more generic one. I'm not 100% sure.

No, I take that back. I think we could add a "NotFragment" value to the enum. I think all parts in teh code will have his same problem (where they have both fragment and non-fragment code paths). Or we could go the other way and remove the "fragment" part from the name if we want it to generically mean some scripting disable functionality.