This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 412 - More willBeModified problems
Summary: More willBeModified problems
Status: RESOLVED FIXED
Alias: None
Product: DOM TS
Classification: Unclassified
Component: DOM Level 3 (show other bugs)
Version: unspecified
Hardware: All All
: P2 minor
Target Milestone: ---
Assignee: Curt Arnold
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-12-12 14:37 UTC by Andrew Clover
Modified: 2003-12-19 22:20 UTC (History)
0 users

See Also:


Attachments
willBeModified changed to true where needed, maybe some mixed bug 425 fixes (392.52 KB, patch)
2003-12-19 16:51 UTC, Curt Arnold
Details
Support for mutation detection (bug 412), reqs removing comments from DOMTest.java (15.06 KB, patch)
2003-12-19 17:18 UTC, Curt Arnold
Details
Transform change to support mutation detection (828 bytes, patch)
2003-12-19 17:20 UTC, Curt Arnold
Details

Description Andrew Clover 2003-12-12 14:37:03 UTC
In the new tests, at least the following:

level3/core/documentnormalizedocument03
level3/core/documentnormalizedocument04
level3/core/noderemovechild05
level3/core/adoptnode (all tests)

Falsely claims the loaded document will not be modified. There are probably
*lots* more cases like these I haven't noticed.

In my opinion, willBeModified should probably be deprecated. Getting it right
even in the face of compliant implementations is proving difficult, and of
course a destructively-uncompliant test-implementation could still modify the
document even in cases where it is not supposed to. If there are any TS
implementations that do cache unmodified documents, they could then give
incorrect results in following tests.

Or is there another use for this attribute than optimisation?
Comment 1 Curt Arnold 2003-12-19 16:51:10 UTC
Created attachment 133 [details]
willBeModified changed to true where needed, maybe some mixed bug 425 fixes
Comment 2 Curt Arnold 2003-12-19 16:59:25 UTC
willBeModified makes the HTML tests runnable.  I believe that most browser 
will die (not just run slowly) unless some document caching is attempted.

I have modified the Java production of <load/> and the backing classes to 
enable detection of modifications to documents that were loaded with 
willBeModified="false".  The DOM L1 Core tests had no violations, but the L2 
Core and L3 Core tests had many.  To enable this checking, you need to 
uncomment out some lines in org.w3c.domts.DOMTest (otherwise it would require 
the org.w3.dom.Events package to be in the classpath).

If there are any remaining inconsistencies, they are either in tests that 
Xerces-J fails or in tests that expect an exception on the first mutation.

Bugzilla was unavailable while I was working on this, so there are some 
intermixed removal of unnecessary implementationAttributes (bug 425) mixed in 
the patch.
Comment 3 Curt Arnold 2003-12-19 17:18:29 UTC
Created attachment 134 [details]
Support for mutation detection (bug 412), reqs removing comments from DOMTest.java
Comment 4 Curt Arnold 2003-12-19 17:20:10 UTC
Created attachment 135 [details]
Transform change to support mutation detection