Community
Participate
Working Groups
With more recent Integration builds in the platform (those including the changes for bug 249214), a number of XML encoding detection unit tests are failing where they used to run correctly. From the looks of it our content describer for malformed XML is no longer being used. According to bug 249314 comment 15, we shouldn't be guessing as it can lead to corrupted data. Comment 7 suggests that it may be preferred to outright fail in those circumstances. Our malformed handler was designed to handle certain errors in the source, specific problems that we could explicitly handle. I've decided that we should continue to do so in those specific cases. In cases where the describer would still fail, however, we should behave like the plain text editor. This would require re-enabling the Set Encoding menu action, but our version of the action should take advantage of a file type's ability to declare its preferred encoding in the source, instead of just relying on the resource properties (which isn't interoperable AFAIK).
Setting to P1 as we've started to cause failures in the 3.1 build.
Comment 0 should refer to bug 249214 comment 15 and bug 249214 comment 9.
These changes bring to light that our ContentDescriberForXML was actually unused in most cases, and the XMLContentDescriber's rules were lax enough where some of these tests were passing. The changes from bug 249214 that affected our tests were not allowing line feeds to be used in the XML declaration and the adherence to the encoding value matching [A-Za-z]([A-Za-z0-9._\\-])*. Right now the ContentTypeCatalog will get a description for the first content type, even if that content type is ultimately deemed INVALID after inspecting the rest of the XML declaration. The ContentTypeCatalog should be changed so that if the content type is invalid (or internalGetDescriptionFor returns null) the other valid or indeterminate content types should be checked. This would permit our ContentDescriberForXML to potentially provide a content description for files that the default could not.
Commented out the following until bug 251748 is resolved: TestContentDescription#testFile111() TestContentDescription#testFile117() TestCodedReader#testFile111() TestCodedReader#testFile117()
Created attachment 115878 [details] junit patch Patched the XML encoding tests to remove all tests that were affected by the fixes in bug 249214. As mentioned in the previous comment, commented out the following until bug 251748 is resolved: TestContentDescription#testFile111() TestContentDescription#testFile117() TestCodedReader#testFile111() TestCodedReader#testFile117() Furthermore, the following were commented out since bug 249214 caused XML files with bad encodings to have a null content descriptions: TestContentTypeDetectionForXML#testFile106() TestContentTypeDetectionForXML#testFile107() TestContentTypeDetectionForXML#testFile107P() TestContentTypeDetectionForXML#testFile113() TestContentTypeDetectionForXML#testFile115() TestContentDescription#testFile115()
The changes to the junits were released to HEAD.
I've opened bug 251786 to address the issue of the ContentTypeCatalog not respecting any other ContentType's descriptions of the content causing null content descriptions to be associated with files that our ContentDescriberForXML could otherwise identify as XML.
We need this "P1" bug resolved before release. Or, have the "P1" parts been done, and waiting on less important items? If so, perhaps this could be resolved and new bugs track the remaining issues.
The original issue of these tests causing failures in the build has been resolved. We do need to explore which of these tests are still valid in light of the changes. I've opened bug 278635 to accomplish this task.
